http://bugs.winehq.org/show_bug.cgi?id=11136
Summary: Trados: TagEditor loosing contact with Workbench. Product: Wine Version: CVS/GIT Platform: HP OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole AssignedTo: wine-bugs@winehq.org ReportedBy: yolande@haneder.biz
When opening Tageditor, it should be able to open and connects to Workbench (working OK yesterday). Now when opening TagEditor, it is prompting Workbench but not seeing it (Workbench is opening although TagEditor says it can't open it).
Showing in the log.
err:ole:apartment_getclassobject DllGetClassObject returned error 0x80040111 err:ole:CoGetClassObject no class object {b196b286-bab4-101a-b69c-00aa00341d07} could be created for context 0x80000001 err:ole:marshal_object couldn't get IPSFactory buffer for interface {b196b284-bab4-101a-b69c-00aa00341d07} err:rpc:I_RpcReceive we got fault packet with status 0x80004002 err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002
Now imagine you try to open a file with TagEditor. It opens the file and is immediately loosing contact with Workbench and ask you if you want to restart Workbench (which is still not closed).
err:ole:StdMarshalImpl_ReleaseMarshalData could not map object ID to stub manager, oxid=4d7000004d8, oid=3 err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error 0x8001011d
It is now opening a SECOND workbench window with again the error.
err:ole:apartment_getclassobject DllGetClassObject returned error 0x80040111 err:ole:CoGetClassObject no class object {b196b286-bab4-101a-b69c-00aa00341d07} could be created for context 0x80000001 err:ole:marshal_object couldn't get IPSFactory buffer for interface {b196b284-bab4-101a-b69c-00aa00341d07} err:rpc:I_RpcReceive we got fault packet with status 0x80004002 err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002
and asking again to reconnect as soon as you point your mouse on the text. Any idea?
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #1 from Austin English austinenglish@gmail.com 2008-01-11 14:18:59 --- Please run a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #2 from Yolande Haneder yolande@haneder.biz 2008-01-11 14:28:04 --- How do you do a regression test between 2 GIT (not 2 versions)? Which ID do you enter?
http://bugs.winehq.org/show_bug.cgi?id=11136
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Keywords| |regression
--- Comment #3 from Dan Kegel dank@kegel.com 2008-01-11 17:11:50 --- The id on the Commit: line of the patch, I think. e.g. for http://winehq.org/pipermail/wine-cvs/2008-January/039198.html you'd use 7514283d7399d620401ccdbfbf04532a9d71199b
I haven't bisected much, so I could be wrong...
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #4 from Austin English austinenglish@gmail.com 2008-01-11 18:07:06 --- (In reply to comment #3)
The id on the Commit: line of the patch, I think. e.g. for http://winehq.org/pipermail/wine-cvs/2008-January/039198.html you'd use 7514283d7399d620401ccdbfbf04532a9d71199b
I haven't bisected much, so I could be wrong...
Yes, git bisect will accept the version or the sha1 commit id.
http://bugs.winehq.org/show_bug.cgi?id=11136
Yolande Haneder yolande@haneder.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aric@codeweavers.com
--- Comment #5 from Yolande Haneder yolande@haneder.biz 2008-01-12 07:16:10 --- Result of the regression test for TagEditor breaking with Workbench as soon as the contact is set is...
0904e34906ccc3c76f8ea2e99faade9dd2feba20 is first bad commit commit 0904e34906ccc3c76f8ea2e99faade9dd2feba20 Author: Aric Stewart aric@codeweavers.com Date: Thu Jan 10 08:01:14 2008 -0600
fonts: Add Japanese small font.
:040000 040000 9f7d38fca7e77a773fe1e4042d58dccd2592cb25 47e3bbcf9139f4d2846bb5484b2bfd1236bca11a M fonts
Note that Trados is able to process the Japanese font.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-12 09:34:31 --- This sounds like an incorrect regression test result to me. If you remove fonts/jsmalle.fon does it help?
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #7 from Yolande Haneder yolande@haneder.biz 2008-01-12 09:49:13 --- To me it does not look incorrect. I bisect from Wednesday to Friday. First bisect was OK. On Friday, just as it got compiled, I still used Trados with the prefix of Thursday afternoon (thus before the new one), it was still stable as on Friday which means that something in the prefix is bad. I did change the prefix to test with word on the new version and bang! it was not working anymore. The only thing TagEditor has in common with word is the spellcheck but there Japanese is not installed. It will then be quicker to look for what in the prefix changed before that time.
I will try however if I find this file. I don't think another test will show something else because for everything except the 1st it was bad.
It is possible that two commits are playing together because on the the 1st commit (good), TagEditor was not able to open Workbench, I did it manually and it was stable. On 0.9.53, TagEditor is opening Workbench but loosing it immediately (or opening a new one).
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #8 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-12 10:00:59 --- (In reply to comment #7)
On Friday, just as it got compiled, I still used Trados with the prefix of Thursday afternoon (thus before the new one), it was still stable as on Friday which means that something in the prefix is bad. I did change the prefix to test with word on the new version and bang! it was not working anymore.
The above confirms that the result of the regression test is incorrect, since Wine doesn't copy builtin fonts to ~/.wine.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #9 from Yolande Haneder yolande@haneder.biz 2008-01-13 12:26:38 --- I am sorry, I can't offer much more on the side of the regression test.
Today I noticed that Workbench and Tag Editor are stable as long as no text is opened. When opening a text however, it just crashed after having checked that the language of the text is the same as of the translation memory.
When you get the error message, the correct language pair (matching the TM) is still shown at the bottom. Once click OK on the message that the connection is lost, the text remains open and the language pair at the bottom is lost. However if you open a bilingual text (which means that already have language tags) with wrong language pair, you first get the message that the language pair does not match the language of the translation memory and that the communication will be cut until you open the right language.
The interesting thing in this however is that even you can't translate, you can click on open/get (function of Workbench) which should not be allowed if the communication is cut.
If you get a bilingual document with the right language pair, it is crashing.
It's like it's only stable when it should not be allowed to communicate and crashing when a communication should be done.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #10 from Yolande Haneder yolande@haneder.biz 2008-01-14 03:41:44 --- Another thing I noticed:
When closing the window or the several Workbench windows that had been called by TagEditor, I get the message error "R6025 pure virtual function call (from Workbench's .exe)" when clicking on the "x" (closing the window) of Workbench.
This also happens when Opening Workbench and TagEditor individually (when opening TagEditor after workbench it automatically makes the connection).
This however does not happen when opening and closing Workbench alone (no connection).
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #11 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-14 03:52:19 --- You still not answered the question: if you remove fonts/jsmalle.fon does it help?
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #12 from Yolande Haneder yolande@haneder.biz 2008-01-14 04:04:53 --- I can't find it on my prefix.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #13 from Yolande Haneder yolande@haneder.biz 2008-01-14 04:06:14 --- Reverting this change through GIT is creating conflicts and aborting.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #14 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-14 04:09:17 --- It should be in /usr/local/wine/fonts if you have installed Wine, otherwise it's under fonts/ in the source tree.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #15 from Yolande Haneder yolande@haneder.biz 2008-01-14 04:39:24 --- I have absolutely no font directory there. In user/local/lib/wine is no font directory. in user/local/ no wine directory.
Usually I have two places for the fonts. In /home/yolande/.fonts (where I install the .ttx fonts, register them in Linux and they get used by wine) or within the wine prefix.
The .fon files are probably somewhere else.
I will see if I can manually change the file in wine-git
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #16 from Yolande Haneder yolande@haneder.biz 2008-01-14 05:24:44 --- I don't think it makes sense for me to manually revert it before I understand which other commit is based on this one.
For one, because GIT refused to revert it since it seemed that another commit was based on this one and it should be reverted too in that case and I don't know which one and also because at the most it would give me the same result as the last bisect i.e. a bad result.
http://bugs.winehq.org/show_bug.cgi?id=11136
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression |
--- Comment #17 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-14 05:43:06 --- Then it doesn't make sense to declare this bug as a regression, and blame a particular commit. Until you have more information I'll remove the keyword 'regression'.
http://bugs.winehq.org/show_bug.cgi?id=11136
Yolande Haneder yolande@haneder.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|aric@codeweavers.com |
--- Comment #18 from Yolande Haneder yolande@haneder.biz 2008-01-14 05:50:26 --- I agree to this. Theoretically it is a regression to me because it worked the day before (I did even translate with the matched language pair). I would however be surprised that it comes because of it since I saw that had something to do with the prefix too. I exchanged every dlls one after the other and didn't get any result either.
I guess I won't have to expect any fix any soon.
Sorry for having accused anybody.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #19 from Yolande Haneder yolande@haneder.biz 2008-01-15 02:27:05 --- Created an attachment (id=10265) --> (http://bugs.winehq.org/attachment.cgi?id=10265) log of last GIT with +rpct4
Sounds the most interesting of all logs
http://bugs.winehq.org/show_bug.cgi?id=11136
Yolande Haneder yolande@haneder.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #10265|0 |1 is obsolete| |
--- Comment #20 from Yolande Haneder yolande@haneder.biz 2008-01-15 03:38:39 --- Created an attachment (id=10269) --> (http://bugs.winehq.org/attachment.cgi?id=10269) correctly with +rpc this time
Another log this time corrected. Please note that it had been done on yesterday's GIT and there TagEditor is not opening Workbench anymore again. Thus this is a log only for Workbench since I had to open a second thread for TagEditor. Tag Editor log is not showing any specific error message.
http://bugs.winehq.org/show_bug.cgi?id=11136
Yolande Haneder yolande@haneder.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #10269|0 |1 is obsolete| |
--- Comment #21 from Yolande Haneder yolande@haneder.biz 2008-01-16 03:36:49 --- Created an attachment (id=10296) --> (http://bugs.winehq.org/attachment.cgi?id=10296) new +rpc log after another bug fixed yesterday
It seems now that it is not always crashing immediately after making the connection but after a few seconds. The log looks different in some parts too.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #22 from Yolande Haneder yolande@haneder.biz 2008-01-16 11:10:07 --- Created an attachment (id=10302) --> (http://bugs.winehq.org/attachment.cgi?id=10302) log with today's GIT
A bit more stable today, holds about 4 seconds before shutting up with usually a pause in the log after "trace:rpc:I_RpcFreeBuffer (0x33f988) Buffer=0x18bfd0".
No crash or C++ error when closing.
http://bugs.winehq.org/show_bug.cgi?id=11136
Yolande Haneder yolande@haneder.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #10296|0 |1 is obsolete| |
--- Comment #23 from Yolande Haneder yolande@haneder.biz 2008-01-16 12:01:18 --- Created an attachment (id=10305) --> (http://bugs.winehq.org/attachment.cgi?id=10305) same with +rpc +ole
This time I had the C++ exception. I don't know why I didn't have it the first time then.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #24 from Dan Kegel dank@kegel.com 2008-01-16 12:03:29 --- If you're having exceptions, you might want to add +seh into your WINEDEBUG options to illuminate them better.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #25 from Yolande Haneder yolande@haneder.biz 2008-01-16 12:21:06 --- There is nothing about the seh except for the line trace:seh:start_debugger Starting debugger "winedbg --auto 1247 448" The debugger is however starting when closing the file so it is showing nothing because at that point the process had already ended.
I don't think that the problem has to do with it, it only occurs after that the problem making the crash seemed to corrupt an entry (no exception when simply closing workbench)
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #26 from Yolande Haneder yolande@haneder.biz 2008-01-16 16:05:42 --- I think I got it!
That's exactly a continuation of the Gdi problem! On the 1st try it only crash after 4-5 seconds, writing an invalid data where it tried to write 2 days ago the huge bitmap. Now it is writing something incorrect about something else on the same go. On any subsequent try, it tries to take this data again from a corrupt temp file, is crashing immediately and furthermore has a C++ error because an invalid flag/setting.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #27 from Yolande Haneder yolande@haneder.biz 2008-01-17 01:12:18 --- Now I don't think it will be solved for anytime soon. I cleared my temp in .wine to see what's happening. First time as I said it hold for 4-5 seconds, TagEditor is opening Workbench. Then after closing the first time, 2 files in z:/temp are disappearing and a file "mapping-yolande, 0 byte, x-special/socket is appearing" Once this file is there it is crashing everytime. Deleting this file and it is crashing too. It seems that this file (0byte) is corrupted due to the directory check and last week as it work I did manage to revert it, which is not working anymore because of dependencies.
It is then invalid or won't fix, but there is no point spending time on this issue at the time being.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #28 from Yolande Haneder yolande@haneder.biz 2008-01-17 04:21:56 --- On the directory /tmp/.wine-1000/server_****-*****/, lock and socket remain at 0 byte even while testing. This does not seem right to me. When deleting the directory for the last test, Wine is creating a new lock/and socket and this is the point where it keeps open for a few seconds. When this directory it already there, it crashed immediately. I don't think this has anything to do with the directory check because I can find directories for all my regression tests of the last weeks.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #29 from Yolande Haneder yolande@haneder.biz 2008-01-17 04:33:00 --- On the days where it worked last week, I have only lock in the respective directories. On the trials with the crash, I have lock and socket. Maybe that's the reason (or the beginning of...)
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #30 from Alexandre Julliard julliard@winehq.org 2008-01-17 04:41:25 --- If you are messing with the files in the server directory then you will see all sorts of problems, but they are not the cause of whatever your real problem is. Don't touch anything in /tmp that you don't understand.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #31 from Yolande Haneder yolande@haneder.biz 2008-01-17 05:05:46 --- I am not messing as you say. I just noticed that I had a directory for each prefix I created. Prefix of wednesday, thursday and Friday 1 (where I made a quick check with the new version before reinstalling a new prefix) have only lock. Friday 2 (0.9.53 + new prefix) and later have 2 files (lock and socket). Getting the last directory resets to the same point as my first test on a new prefix (where a new directory is created without C++ error), later tests with the directory there and I have the C++ error with immediate crash.
I don't bother with testing. As far as I am I have nothing to loose if I have to reinstall everything. Until now I didn't even see this directory.
http://bugs.winehq.org/show_bug.cgi?id=11136
Yolande Haneder yolande@haneder.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #10302|0 |1 is obsolete| | Attachment #10305|0 |1 is obsolete| |
--- Comment #32 from Yolande Haneder yolande@haneder.biz 2008-01-18 07:18:10 --- Created an attachment (id=10340) --> (http://bugs.winehq.org/attachment.cgi?id=10340) New log with today's GIT
First try - Quite at the beginning of the log I found
trace:rpc:rpcrt4_conn_open_pipe connecting to \.\pipe\lrpc\irot warn:rpc:rpcrt4_conn_open_pipe connection failed, error=e7
It does only happens once, although the rest afterwards is repeated again and again. It might be of some importance.
http://bugs.winehq.org/show_bug.cgi?id=11136
--- Comment #33 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-18 08:25:15 --- I'd suggest to stop attaching the arbitrary logs to thos bug, Unless a developer asked to generate the log, and he is going to investigate it these logs are useless. To me it looks like you are trying to follow a stray path.
http://bugs.winehq.org/show_bug.cgi?id=11136
Yolande Haneder yolande@haneder.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #34 from Yolande Haneder yolande@haneder.biz 2008-02-19 11:31:00 --- .
http://bugs.winehq.org/show_bug.cgi?id=11136
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #35 from Dan Kegel dank@kegel.com 2008-02-22 11:39:57 --- 0.9.56 released, so closing all bugs marked as RESOLVED FIXED.
http://bugs.winehq.org/show_bug.cgi?id=11136
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
http://bugs.winehq.org/show_bug.cgi?id=11136
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|HP |PC
--- Comment #36 from Dan Kegel dank@kegel.com 2009-05-29 19:01:00 --- Bugs marked "HP, Linux" probably should have been marked "PC, Linux" as HP really is for HP's HP-PA or Itanium systems, and very few people have those.
https://bugs.winehq.org/show_bug.cgi?id=11136
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ole |-unknown
https://bugs.winehq.org/show_bug.cgi?id=11136
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |0.9.53. CC| |focht@gmx.net
-
wine-bugs＠winehq.org