wine-bugs November 2007

wine-bugs@winehq.org

19 participants
2259 discussions

[Bug 10079] New: "make test" hangs on ole32/moniker
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=10079 Summary: "make test" hangs on ole32/moniker Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Severity: critical Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com This one is wierd. It gets stuck in a loop where rpcss.exe crashes over and over. err:ole:RPC_StartRemoting Couldn't register endpoint L"\\pipe\\OLE_0000000800000009" fixme:ole:PSFacBuf_CreateStub stubbing not implemented for ({0000000f-0000-0000-c000-000000000046}) yet! err:ole:marshal_object Failed to create an IRpcStubBuffer from IPSFactory for {0000000f-0000-0000-c000-000000000046} with error 0x80004005 err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80004005 err:ole:CoMarshalInterface Failed to marshal the interface {0000000f-0000-0000-c000-000000000046}, 80004005 wine: Unhandled page fault on read access to 0x8000012c at address 0x701069b2 (thread 000e), starting debugger... Unhandled exception: page fault on read access to 0x8000012c in 32-bit code (0x701069b2).... Backtrace: =>1 0x701069b2 in rpcrt4 (+0x69b2) (0x0034fd58) 2 0x7efa1875 call_dll_entry_point+0x15() in ntdll (0x0034fd78) 3 0x7efa323d MODULE_InitDLL+0x8d(wm=<register EDI not in topmost frame>, reason=<register ESI not in topmost frame>, lpReserved=0x1) [/home/dank/wine-git/dlls/ntdll/loader.c:890] in ntdll (0x0034fe08) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 9829] New: Unable to start Alien Shooter 2 demo
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=9829 Summary: Unable to start Alien Shooter 2 demo Product: Wine Version: 0.9.46. Platform: PC URL: http://www.sigma- team.net/alienshooter_2/upload/as2demo.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: karaluh(a)tlen.pl The game quits after initial loading screen. Resolution isn't changed back, wine doesn't crash. The last error message is err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded To reproduce: 1. install demo from http://www.sigma-team.net/alienshooter_2/upload/as2demo.exe 2. run the game. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 9887] New: installing panasonic software
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=9887 Summary: installing panasonic software Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: baddraz(a)hotmail.com Created an attachment (id=8380) --> (http://bugs.winehq.org/attachment.cgi?id=8380) Panasonic maintenance console Get errors while attempting to install Panasonic Maintenance Console -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 7

[Bug 10109] New: "make test" fails in itss/tests/protocol.c
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=10109 Summary: "make test" fails in itss/tests/protocol.c Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Blocks: 9916 WINEDEBUG=warn+heap make test fails in itss with protocol.c:307: Test failed: expected ReportProgress_MIMETYPEAVAILABLE -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 7

[Bug 10186] New: Scary heap warnings in ole32 tests
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=10186 Summary: Scary heap warnings in ole32 tests Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Doing cd dlls/ole32/tests rm *.ok export WINEDEBUG=warn+heap make -k test yields a couple scary heap warnings. In particular, ../../../tools/runtest -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so hglobalstream.c && touch hglobalstream.ok warn:heap:GlobalLock invalid handle 0x125852 (Magic: 0x0098) ../../../tools/runtest -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so moniker.c warn:heap:HEAP_ValidateInUseArena Heap 0x110000: unaligned arena pointer 0x12ba7c warn:heap:HEAP_ValidateInUseArena Heap 0x110000: unaligned arena pointer 0x12bafc In tests/hglobalstream.c near line 286, there is the code hr = CreateStreamOnHGlobal(hglobal, FALSE, &pStream); ... GlobalFree(hglobal); ... hr = IStream_Read(pStream, buffer, sizeof(buffer), &read); and the IStream_Read is what triggers the invalid handle warning. The test code seems quite intentional, and the test passes on wine; is the warning spurious? In tests/moniker.c, there's a double release of a pointer at line 937, and removing one of them makes one warning go away; is this a typo, or intended? IEnumMoniker_Release(spEM1); IEnumMoniker_Release(spEM1); -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

[Bug 10599] New: dlls/oleaut32/tests/vartest.c fails
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=10599 Summary: dlls/oleaut32/tests/vartest.c fails Product: Wine Version: CVS/GIT Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: test AssignedTo: wine-bugs(a)winehq.org ReportedBy: alexandru.balut(a)gmail.com I'm running "make test" from dlls/oleaut32/tests and I get this error: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so vartest.c && touch vartest.ok fixme:variant:VarMod Could not convert left type 4096 to 20? rc == 0x80020008 fixme:variant:VarMod Could not convert left type 8192 to 20? rc == 0x80020008 fixme:variant:VarMod Could not convert left type 16384 to 20? rc == 0x80020008 vartest.c:3143: Test failed: got VT_DATE(-1.5) expected VT_DATE(-1.4) vartest.c:3150: Test failed: got VT_R8(-1.5) expected VT_R8(-1.4) make: *** [vartest.ok] Error 2 I use wine-0.9.49-376-gc2f0697 on Ubuntu Gutsy (2.6.22-14-generic #1 SMP x86_64 GNU/Linux), the compiler is gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) There is a similar report here: http://www.winehq.org/pipermail/wine-devel/2007-August/058585.html -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 9

[Bug 9575] New: IBExpert need windows native ole32.dll to run
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=9575 Summary: IBExpert need windows native ole32.dll to run Product: Wine Version: 0.9.44. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: c_pradelli(a)yahoo.com To run ibexpert ole32.dll needs to be overriden (or dcom98 installed). I can't detect why, there are no fixme printed on screen. The application raise an access violation when starts and then you can't close it. The application is in AppDB http://appdb.winehq.org/appview.php?iVersionId=9049 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 33

[Bug 9401] New: Dragon Naturally Speaking 7 crashes after training complete
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=9401 Summary: Dragon Naturally Speaking 7 crashes after training complete Product: Wine Version: CVS Platform: Other URL: http://scansoft.com OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Created an attachment (id=7715) --> (http://bugs.winehq.org/attachment.cgi?id=7715) +ole log of running training, and error that happened shortly thereafter After user training is complete, DNS puts up a dialog saying something like "Congratulations! Training is complete." The next thing you do crashes with a dialog box saying something like "Unexpected error. COM out of memory." and log messages like Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x0 0000000). Fortunately, the error repeats the next time you start and try to do something, you don't have to repeat training. Better make a copy of ~/.wine once you finish training, though, so you can get back to that state quickly in case something goes wrong. (e.g. running a +relay log at that point filled up my disk, and after that, dragon wouldn't start properly.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

[Bug 9388] New: installer stuck for TRS 2006 Demo
by wine-bugs＠winehq.org 06 Jan '16

06 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=9388 Summary: installer stuck for TRS 2006 Demo Product: Wine Version: CVS Platform: PC-x86-64 URL: http://www.auran.com/TRS2006/index.php OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.org ReportedBy: dan(a)danny.cz When trying to install the demo for TRS 2006, the installer gets stuck on the first installation wizard page. output from the terminal: fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" err:ole:TLB_ReadTypeLib Loading of typelib L"c:\\Program Files\\Common Files\\InstallShield\\Professional\\RunTime\\IsProBE.tlb" failed with error 2 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 10417] New: OLEAUT32: crash if >128 methods in an interface
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=10417 Summary: OLEAUT32: crash if >128 methods in an interface Product: Wine Version: 0.9.49. Platform: Macintosh OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P1 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: mjk(a)cardbox.com This bug was encountered in build cxoffice-6.2.0rc1-2-g024be42 of Wine (part of CrossOver Mac). The bug has been identified in the current source code at http://source.winehq.org/source/dlls/oleaut32/tmarshal.c. Using any marshaled interface with more than 128 methods causes a crash within OLEAUT32 if any method at position >=128 is called. This was detected when using Cardbox (http://www.cardbox.com) and is a SHOW-STOPPER because it makes the use of VBScript macros impossible. However, the bug is completely general and applies to any application at all that has interfaces with large number of methods. It is quite possible that many random OLE / COM - related bugs that have already been reported have this bug as their underlying cause. The version of Cardbox on which the bug was found is more recent than the one currently available on the web site. If anyone wants to have a copy for testing, together with instructions for reproducing the crash, please contact me. LOCATION OF THE BUG The bug is in dlls/oleaut32/tmarshal.c. When constructing a proxy interface, PSFacBuf_CreateProxy at line #1712 constructs the following proxy code for each method: popl %eax pushl <nr> pushl %eax call xCall lret <n> (+4) where <nr> is the position of the method in the list of methods: 0, 1, 2, and so on. The pushl <nr> instruction is defined by following code: 374 BYTE pushlval; // set to 0x6a by line #1712 375 BYTE nr; The fact that the method position is a byte already limits the maximum size of an interface to 256 methods, which is less than the 512-method limit of Windows NT4.0 SP3, and the 1024-method limit of Windows 2000: see "MIDL2362" in http://msdn2.microsoft.com/en-us/library/aa366756.aspx for details. Thus this needs to be corrected in any case. The proxy code as it stands will call method 0 instead of method 256, method 1 instead of method 257, and so on, leading to random behaviour and possible stack corruption. The crash when method 128 is called has a different cause. The proxy for method 128 contains the instruction 6A 80, because the programmer thought that this would push 00000080 onto the stack. In fact the PUSH instruction with opcode 6A SIGN-EXTENDS its operand and does not zero-extend it. Thus the proxy for the 128th method pushes FFFFFF80 onto the stack before calling xCall. xCall interprets this as a negative number (-128) and thus attempts to synthesize a call not to method 128 but to a non-existent method -128. In the same way it will call method -127 instead of method 129,... and so on. SUGGESTED CORRECTION The very simple correction to this bug, which is guaranteed to work, is to alter line 375 to 375 DWORD nr; and line 1712 to 1712 xasm->pushlval = 0x68; which expects a 32-bit operand rather than an 8-bit one. This will result in every proxy using 15 bytes per method instead of 12 bytes. This does not seem an excessive price to pay for complete reliability in the future: there will then be no limit to the number of methods that can be supported. ALTERNATIVE CORRECTIONS If the 25% expansion in proxy size is considered unacceptable (it should not really be: proxies are small) then there are several ways round the problem. An increase to 256 methods could be achieved simply by adding a line at the very beginning of xCall: method &= 0xff; but this would HAVE to be accompanied by an explicit test for the method count limit (now 256) in PSFacBuf_CreateProxy so that the attempt to create a proxy with too methods would simply fail rather than (as now) generate a proxy that will randomly crash the application. Another approach would be to create dummy functions (in assembler) that would add 128, 256, 384, 512, etc to the 'method' argument before forwarding it on to xCall. In that case, method numbers after 127 would generate proxies that called one of the variant xCalls instead of the original one. The programming in PSFacBuf_CreateProxy would be relatively straightforward, and the dummy functions would not need to do any stack manipulation: they would simply add an offset to the DWORD at [ESP+8] and then JMP straight to the start of xCall. This would *still* give a finite limit to the number of methods, but the limit would be much larger. Again, good engineering practice dictates that PSFacBuf_CreateProxy should report an error if it encounters a number of methods beyond the number that it was designed to cope with. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs November 2007