July 2014 - Wine-Devel - list.winehq.org

Re: mshtml: Fixed typos in HTMLTable_QI.

by Zhenbo Li

On 07/15/2014 02:21 AM, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> --- >> dlls/mshtml/htmltable.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > It doesn't work: I think another patch is needed: diff --git a/dlls/mshtml/htmltable.c b/dlls/mshtml/htmltable.c index de12537..484032f 100644 --- a/dlls/mshtml/htmltable.c +++ b/dlls/mshtml/htmltable.c @@ -969,6 +969,8 @@ HRESULT HTMLTable_Create(HTMLDocumentNode *doc, nsIDOMHTMLElement *nselem, HTMLE ret->element.node.vtbl = &HTMLTableImplVtbl; ret->IHTMLTable_iface.lpVtbl = &HTMLTableVtbl; + ret->IHTMLTable2_iface.lpVtbl = &HTMLTable2Vtbl; + ret->IHTMLTable3_iface.lpVtbl = &HTMLTable3Vtbl; HTMLElement_Init(&ret->element, doc, nselem, &HTMLTable_dispex); Should I squash them? Thanks. > > ../../../tools/runtest -q -P wine -T ../../.. -M mshtml.dll -p mshtml_test.exe.so dom && touch dom.ok > wine: Unhandled page fault on read access to 0x00000004 at address 0x558bae66 (thread 0069), starting debugger... > Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x558bae66). > Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b > EIP:558bae66 ESP:0032f7d0 EBP:0032f808 EFLAGS:00210202( R- -- I - - - ) > EAX:028c05c4 EBX:55977e38 ECX:0bcebd00 EDX:00000000 > ESI:0032f8cc EDI:686b0350 > Stack dump: > 0x0032f7d0: 028c05c4 686b0350 00000010 55923438 > 0x0032f7e0: 028c0558 0032f8cc 00000010 028c0558 > 0x0032f7f0: 028c0574 683e2b20 558bae0b 686c8a40 > 0x0032f800: 686b0350 0032f8cc 0032f828 5589c3b5 > 0x0032f810: 028c0558 686b0350 0032f8cc 686c8a40 > 0x0032f820: 686b0360 00000000 0032f848 5587658d > Backtrace: > =>0 0x558bae66 HTMLTable_QI+0x66(iface=0x28c0558, riid=0x686b0350, ppv=0x32f8cc) [/home/julliard/wine/wine/dlls/mshtml/htmltable.c:924] in mshtml (0x0032f808) > 1 0x5589c3b5 HTMLDOMNode_QueryInterface+0x24(iface=0x28c0568, riid=0x686b0350, ppv=0x32f8cc) [/home/julliard/wine/wine/dlls/mshtml/htmlnode.c:474] in mshtml (0x0032f828) > 2 0x5587658d HTMLElement_QueryInterface+0x2c(iface=<couldn't compute location>, riid=<couldn't compute location>, ppv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/mshtml/../../include/mshtml.h:15891] in mshtml (0x0032f848) > 3 0x55854e3c DispatchEx_QueryInterface+0x2b(iface=<couldn't compute location>, riid=<couldn't compute location>, ppv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/mshtml/dispex.c:1316] in mshtml (0x0032f878) > 4 0x6863f0e5 _test_ifaces+0x54(line=<is not available>, iface=<is not available>, iids=0x686c85e0) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:552] in mshtml_test (0x0032f8e8) > 5 0x6863f604 _test_elem_type+0x43(line=0x198f, unk=0x28c0558, type=ET_TABLE) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:1034] in mshtml_test (0x0032f918) > 6 0x68641178 _test_elem_collection+0x4f7(line=0x198f, unk=<is not available>, elem_types=0x686a76a0, exlen=0x1e) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:2153] in mshtml_test (0x0032fa98) > 7 0x68650746 test_elems+0x95(doc=0x28b2b38) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:6543] in mshtml_test (0x0032fc88) > 8 0x686470e7 run_domtest+0x2f6(str=<is not available>, test=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:8099] in mshtml_test (0x0032fd08) > 9 0x686556e6 func_dom+0x115() [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:8126] in mshtml_test (0x0032fd48) > 10 0x6862d96f main+0x37e(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/wine/test.h:584] in mshtml_test (0x0032fe18) > 11 0x686a0850 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mshtml_test (0x0032fe58) > 12 0x7b85f65c call_process_entry+0xb() in kernel32 (0x0032fe78) > 13 0x7b8606a3 start_process+0x62(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1097] in kernel32 (0x0032feb8) > 14 0x7bc7fac0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) > 15 0x7bc82a6d call_thread_func+0x7c(entry=0x7b860640, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2630] in ntdll (0x0032ffa8) > 16 0x7bc7fa9e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) > 17 0x7bc53f0e start_process+0x1d(kernel_start=0x7b860640) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2856] in ntdll (0x0032ffe8) > 18 0x680316dd wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > 19 0x6803179b wine_switch_to_stack+0x2a(func=0x7bc53ef0, arg=0x7b860640, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xff808918) > 20 0x7bc59a09 LdrInitializeThunk+0x238(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2910] in ntdll (0xff808958) > 21 0x7b866ea3 __wine_kernel_init+0xa02() [/home/julliard/wine/wine/dlls/kernel32/process.c:1269] in kernel32 (0xff809858) > 22 0x7bc5a903 __wine_process_init+0x192() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3119] in ntdll (0xff8098e8) > 23 0x6802ede8 wine_init+0x2c7(argc=0x3, argv=0xff809e24, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:952] in libwine.so.1 (0xff809948) > 24 0x7bf00d6c main+0x7b(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xff809d88) > 25 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x00000000) > 0x558bae66 HTMLTable_QI+0x66 [/home/julliard/wine/wine/dlls/mshtml/htmltable.c:924] in mshtml: call *0x4(%edx) > 924 IUnknown_AddRef((IUnknown*)*ppv); >

July 15, 2014

Re: [PATCH 2/2] vbscript/tests: Added tests for the subtype of TypeName(try 4) )

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7988 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

July 15, 2014

Re: [PATCH 1/2] vbscript: Implemented Abs(try 8)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7987 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

July 15, 2014

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText. (try 3)

by Jactry Zeng

Hi Huw, diTextEnd is useful for append a '\r' to the last paragraph. But because of bug of EM_SETSEL or EM_GETSEL, this feature still cannot be implemented completely. For example: When the text in Rich Edit control is: "TestSomeText" 01234567890123 We cannot distinguish between SendMessageA(w, EM_SETSEL, 0, 12) and SendMessageA(w, EM_SETSEL, 0, 13). Attachment is the patch, I just added wine_todo for failed tests cause by this bug. But I still have no idea about fixing this bug. Could you give me some suggestion? Or just mark them as todo now is OK? Thank you! 2014-07-07 16:38 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > On Fri, Jul 04, 2014 at 07:00:16PM +0800, Jactry Zeng wrote: > > A few weeks ago, I have made some tests about this problem. And it seem > is an > > unimplement feature of Rich edit control and should not be fixed in > ME_GetTextW > > or ITextSeletction::GetText simply: > > > > 1. end-of-story is different from end-of-paragraph > > From document of ITextDocument::GetStoryCount: Rich edit controls have > only one > > story.[1] > > So ‘story’ may is an unit like 'paragraph' in Rich edit control. We may > need > > add a MERF_ENDSTORY to implement it.[2] > > > > 2. What does the end-of-story looks like? > > When we run the wordpad with native riched20, we can use ‘ctrl + shitf + > →’ to > > select the ‘space’ at the end of the Rich edit control. But we cannot > set the > > cursor behind it.(a picture here[3]) > > And wine’s riched20 didn’t implement this ‘space’. This 'space' may is > the end- > > of-story. > > > > A crash will happen when we copy the ‘space’ from a native Rich edit > control to > > a builtin one.(backtrace.txt[4]) > > > > BTW, there is a know bug of EM_SETSEL: cannot select the last character > of Rich > > edit control.[5] > > > > 3. > > From the last paragraph of this blog: > http://blogs.msdn.com/b/murrays/archive/ > > 2008/11/22/paragraphs-and-paragraph-formatting.aspx > > It is sure there is a final EOP in a Rich edit control. > > > > There seems to be every indication that we should implement the final > EOP of > > Rich edit control rather than just append a ‘\r’ in > ITextSelection::GetText. > > So I just let a FIXME comment there. I am not sure if I am right. > > Do you have any suggestion? > > Well first of all, if there are bugs with the underlying richedit, > these need fixing first. Note, that every richedit consists of at > least one paragraph (and hence one final EOP). > > I was suggesting adding to ME_GetTextW the ability to append a '\r' if it > were passed an appropriate flag, of course this wouldn't be the behaviour > used for its current callers. There's already a diTextEnd item in the > display list to mark the end of the document, so there should be no > need to add a new end-of-story marker. Most of the iterator functions > stop when this is reached, so you tend not to actually see it, but > that shouldn't be a problem. > > Huw. > -- Regards, Jactry Zeng

July 15, 2014

Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Andrei Slăvoiu

În ziua de Lun 14 Iul 2014, la 22:58:40, Henri Verbeet a scris: > On 14 July 2014 21:22, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > > I see on Nvidia's site that the oldest cards supported by the legacy > > drivers on Linux are Geforce 5 FX series. So is it ok if I just remove > > all the D3D8 and lower cards completely? > > Possibly, but it's a bit besides the point. You can't match against > something generic like "GeForce", and returning CARD_NVIDIA_RIVA_TNT > instead of PCI_DEVICE_NONE breaks the fallback mechanism. Yes, I realize now this was completely broken, and patch nr. 3 was just a partial fix for the damage I done here. But how do I get the exact renderer string for those old cards? I guess from the comments that the original Geforce cards or either identified as "Geforce 256" or "Geforce DDR". But what about the Quadro cards? How do I make those less generic? So the easy fix is to just get rid of those old cards identified by such generic strings. Now the question is how should I update the series, the current patch 3 no longer makes sense, and removing the old Nvidia cards should have been a change of its own before this one. Is it ok to renumber patches 1 and 2 as 2 and 3 and make a new patch 1 or should I keep the original numbering, scrap patch 3 and remove the old cards as part of the gl_info removal?

July 14, 2014

Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Henri Verbeet

On 14 July 2014 21:22, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > I see on Nvidia's site that the oldest cards supported by the legacy drivers > on Linux are Geforce 5 FX series. So is it ok if I just remove all the D3D8 > and lower cards completely? Possibly, but it's a bit besides the point. You can't match against something generic like "GeForce", and returning CARD_NVIDIA_RIVA_TNT instead of PCI_DEVICE_NONE breaks the fallback mechanism.

July 14, 2014

Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Andrei Slăvoiu

În ziua de Lun 14 Iul 2014, la 21:30:43, Stefan Dösinger a scris: > Am 2014-07-14 21:22, schrieb Andrei Slăvoiu: > > În ziua de Lun 14 Iul 2014, la 18:38:09, Henri Verbeet a scris: > >> What happens is that the renderer string is "GeForce > >> 210/PCIe/SSE2", which now ends up getting matched against > >> "GeForce", and the rest mostly just follows from there. > > > > I see on Nvidia's site that the oldest cards supported by the > > legacy drivers on Linux are Geforce 5 FX series. So is it ok if I > > just remove all the D3D8 and lower cards completely? > > Aren't there different legacy drivers for even older cards? I think we > still have some (>= 1) users that use GeForce 4 MX cards(*), which are > actually just GeForce 2 GPUs. > > (*): http://bugs.winehq.org/show_bug.cgi?id=34574 So leave those supported by driver 96.43.23, that would be all D3D8 cards + Geforce4 MX. Previous to that was driver 71.86.15 from August 2011. I hope nobody uses that with a recent wine version any more.

July 14, 2014

Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-07-14 21:22, schrieb Andrei Slăvoiu: > În ziua de Lun 14 Iul 2014, la 18:38:09, Henri Verbeet a scris: >> What happens is that the renderer string is "GeForce >> 210/PCIe/SSE2", which now ends up getting matched against >> "GeForce", and the rest mostly just follows from there. > > I see on Nvidia's site that the oldest cards supported by the > legacy drivers on Linux are Geforce 5 FX series. So is it ok if I > just remove all the D3D8 and lower cards completely? Aren't there different legacy drivers for even older cards? I think we still have some (>= 1) users that use GeForce 4 MX cards(*), which are actually just GeForce 2 GPUs. (*): http://bugs.winehq.org/show_bug.cgi?id=34574 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTxC/iAAoJEN0/YqbEcdMwEyQP/1/lfu5+kh/Z/826AzVerd3j YmL1huZ0dIG4c48LFUGHKeeOgN9uALUomeZiubdIPgXR73Gj67lYbiqybpZETmKi wdFXkWH5qQbED5kAH997NAPE8CM1b1q9LDR7+AABqSrCRdhNsTpfVutuoPtGTL2a c+iXKMmT0ASd9ML25PJxcQl2Ur4s10/JXBF/z2ctMq683xtYzCIuEvgXYxO25nCP VXxYstFqgdFNHAFMH4D2RHdg72s84JGUPVoTVH1L2aowiBkocqkPLPLercpJTyBf vvhN/asRbPX0e1ne0ywuJ29xMxm+QdhPlhR/Pl4jfgtJmv7NLuiBJcENfTun8RNG uI5e0cp3xFXARKTLU0N8KjMdOE2kRXKHcDAEr+UpP9GIO17QC0guo2bmnuf6yaNc hFPlO4LMEFPIOfoi+MBl5EHWI1be6p9PVubqoxcAr3p4CH4uZ2xdJxn1zX4sd68a T+dB2KgMAhsmWrEpssfzFPCq4mUefQOKUnrp+Qf96/e+XjC6F7hID3kQumox1RT0 K6a2uZx2xtmcyeJlpsNhQC5xtUo52FsBxaRUAOQpeyqHN9SFdy6WA9zoPqae/mRE CuWnTwQWQcmYXRq4eY8i3j107/1BzmKbz6BB1EIEPeKDWMr2es6cJetzKZrkRsxN RXh3AAojahZkBScVxHi9 =tVi6 -----END PGP SIGNATURE-----

July 14, 2014

Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Andrei Slăvoiu

În ziua de Lun 14 Iul 2014, la 18:38:09, Henri Verbeet a scris: > What happens is that the renderer string is "GeForce 210/PCIe/SSE2", > which now ends up getting matched against "GeForce", and the rest > mostly just follows from there. I see on Nvidia's site that the oldest cards supported by the legacy drivers on Linux are Geforce 5 FX series. So is it ok if I just remove all the D3D8 and lower cards completely?

July 14, 2014

Re: mshtml: Fixed typos in HTMLTable_QI.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/htmltable.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -T ../../.. -M mshtml.dll -p mshtml_test.exe.so dom && touch dom.ok wine: Unhandled page fault on read access to 0x00000004 at address 0x558bae66 (thread 0069), starting debugger... Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x558bae66). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:558bae66 ESP:0032f7d0 EBP:0032f808 EFLAGS:00210202( R- -- I - - - ) EAX:028c05c4 EBX:55977e38 ECX:0bcebd00 EDX:00000000 ESI:0032f8cc EDI:686b0350 Stack dump: 0x0032f7d0: 028c05c4 686b0350 00000010 55923438 0x0032f7e0: 028c0558 0032f8cc 00000010 028c0558 0x0032f7f0: 028c0574 683e2b20 558bae0b 686c8a40 0x0032f800: 686b0350 0032f8cc 0032f828 5589c3b5 0x0032f810: 028c0558 686b0350 0032f8cc 686c8a40 0x0032f820: 686b0360 00000000 0032f848 5587658d Backtrace: =>0 0x558bae66 HTMLTable_QI+0x66(iface=0x28c0558, riid=0x686b0350, ppv=0x32f8cc) [/home/julliard/wine/wine/dlls/mshtml/htmltable.c:924] in mshtml (0x0032f808) 1 0x5589c3b5 HTMLDOMNode_QueryInterface+0x24(iface=0x28c0568, riid=0x686b0350, ppv=0x32f8cc) [/home/julliard/wine/wine/dlls/mshtml/htmlnode.c:474] in mshtml (0x0032f828) 2 0x5587658d HTMLElement_QueryInterface+0x2c(iface=<couldn't compute location>, riid=<couldn't compute location>, ppv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/mshtml/../../include/mshtml.h:15891] in mshtml (0x0032f848) 3 0x55854e3c DispatchEx_QueryInterface+0x2b(iface=<couldn't compute location>, riid=<couldn't compute location>, ppv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/mshtml/dispex.c:1316] in mshtml (0x0032f878) 4 0x6863f0e5 _test_ifaces+0x54(line=<is not available>, iface=<is not available>, iids=0x686c85e0) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:552] in mshtml_test (0x0032f8e8) 5 0x6863f604 _test_elem_type+0x43(line=0x198f, unk=0x28c0558, type=ET_TABLE) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:1034] in mshtml_test (0x0032f918) 6 0x68641178 _test_elem_collection+0x4f7(line=0x198f, unk=<is not available>, elem_types=0x686a76a0, exlen=0x1e) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:2153] in mshtml_test (0x0032fa98) 7 0x68650746 test_elems+0x95(doc=0x28b2b38) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:6543] in mshtml_test (0x0032fc88) 8 0x686470e7 run_domtest+0x2f6(str=<is not available>, test=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:8099] in mshtml_test (0x0032fd08) 9 0x686556e6 func_dom+0x115() [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:8126] in mshtml_test (0x0032fd48) 10 0x6862d96f main+0x37e(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/wine/test.h:584] in mshtml_test (0x0032fe18) 11 0x686a0850 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mshtml_test (0x0032fe58) 12 0x7b85f65c call_process_entry+0xb() in kernel32 (0x0032fe78) 13 0x7b8606a3 start_process+0x62(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1097] in kernel32 (0x0032feb8) 14 0x7bc7fac0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 15 0x7bc82a6d call_thread_func+0x7c(entry=0x7b860640, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2630] in ntdll (0x0032ffa8) 16 0x7bc7fa9e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 17 0x7bc53f0e start_process+0x1d(kernel_start=0x7b860640) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2856] in ntdll (0x0032ffe8) 18 0x680316dd wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 19 0x6803179b wine_switch_to_stack+0x2a(func=0x7bc53ef0, arg=0x7b860640, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xff808918) 20 0x7bc59a09 LdrInitializeThunk+0x238(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2910] in ntdll (0xff808958) 21 0x7b866ea3 __wine_kernel_init+0xa02() [/home/julliard/wine/wine/dlls/kernel32/process.c:1269] in kernel32 (0xff809858) 22 0x7bc5a903 __wine_process_init+0x192() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3119] in ntdll (0xff8098e8) 23 0x6802ede8 wine_init+0x2c7(argc=0x3, argv=0xff809e24, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:952] in libwine.so.1 (0xff809948) 24 0x7bf00d6c main+0x7b(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xff809d88) 25 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x00000000) 0x558bae66 HTMLTable_QI+0x66 [/home/julliard/wine/wine/dlls/mshtml/htmltable.c:924] in mshtml: call *0x4(%edx) 924 IUnknown_AddRef((IUnknown*)*ppv); -- Alexandre Julliard julliard(a)winehq.org

July 14, 2014