Problem description: Opening Extras / Options / Internet settings and then either Proxy or Browser Plug-in (German click path: Extras / Optionen / Internet. Proxy or Browser Plug-in) leads to a programm crash. Steps to reproduce: 1. Follow given click path: Extras / Options / Internet settings 2. Then click either Proxy or Browser Plug-in sub option Current behavior: LibreOffice application crashes. Main window is gone. Just the no longer responding options dialog window is visible. Expected behavior: Form should appear in the options dialog to configure a Proxy connection or the Browser Plug-in. Platform (if different from the browser): German Windows 7 Professions 32-Bit Browser: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
*** Bug 47139 has been marked as a duplicate of this bug. ***
Just for the information, I don't reproduce this bug on pc Debian x86-64 with branch 3.5. Fdo#47139 was on Windows too. Could anybody test on MacOS ?
I can reproduce at will in 3.5.3rc1. Instant crash on Windows 7 Professional SP1 (see bug 47139 for my report).
Created attachment 62055 [details] WinDbg session - Tools Options Proxy crash As my original bug report was closed as DUP of this (bug 47139) I am attaching this WinDbg session here. This is what I did to trace this bug: - configured build environment on Windows 7 with Visual Studio 2008 Express - build own LOdev 3.5.2.2 debug build with symbols - added symbols and source paths to WinDbg settings - attached to a soffice.bin process - g - reproduced a crash (click on Tools>Settings>Options>Proxy) - !analyze -v - added Call stack to the output - added source sections from above to the output LO Windows developers - I hope this will give you a clue what is wrong in here, also please write what is missing. mv@triplechaos.com: sorry to take over your bug report but this bug is a blocker for us, as we have constant crashes in our environment, which is: - Active Directory domain - IE proxy autoconfiguration as pac file distributed by GPO to all users - only intranet available - users have normal domain accounts - only Windows 7 hosts are affected - no problems for Windows XP hosts
Sidenote: other potential duplicates: Bug 40592 Bug 48643 Bug 46292 All on Windows 7 system. BTW: confirmed on my own LOdev 3.5.4.2 build.
Created attachment 62322 [details] Bug 47044 - WinDbg session with FAILED_SOURCE_CODE Attached full WinDbg session with FAILED_SOURCE_CODE.
bfoman: first, thank you for your great help retrieving bt with symbols on Windows. I sent a post on dev mailing list here: http://nabble.documentfoundation.org/About-fdo-47044-crashed-when-accessing-Proxy-etc-td3986891.html
*** Bug 46292 has been marked as a duplicate of this bug. ***
*** Bug 40592 has been marked as a duplicate of this bug. ***
*** Bug 48643 has been marked as a duplicate of this bug. ***
Created attachment 62592 [details] patch to gather debug output @bfoman: I cannot reproduce on Windows 7. However, as you state you were able to compile LO from source, can you please produce a build with attached debug3.5.patch applied? (I originally designed that patch for 3.6, and only fixed it to apply to 3.5 while on Linux, so couldn't check that it still builds. Also, short of a complete rebuild, you can do "make shell" and copy the resulting solver/wntmsci12.pro/bin/wininetbe1.uno.dll into the LO installation's program/ directory.) This should produce a number of debug output lines prefixed with "WinInetBackend" when opening "Tools - Options... - Internet - Proxy" (via OutputDebugString, so should be visible when running within WinDbg, or profiling from depends.exe, etc.). If you can make available that debug output, that should help us track down this problem.
(In reply to comment #11) > I originally designed that patch for 3.6, and only > fixed it to apply to 3.5 while on Linux, so couldn't check that it still > builds. Ach, I just notice, you need to remove the spurious "+" at the start of some of the added lines after applying the patch.
(In reply to comment #11) > @bfoman: I cannot reproduce on Windows 7. However, as you state you were able > to compile LO from source, can you please produce a build with attached > debug3.5.patch applied? I will do a build tomorrow and report the results. Should I "make clean" after applying the patch?
(In reply to comment #13) > I will do a build tomorrow and report the results. Great, thanks. > Should I "make clean" after applying the patch? No, better avoid it (as rebuilding from clean takes so much longer). (Just please note my comment 12 on how to massage the patch after application. I'm sberg on #libreoffice-dev freenode irc, in case you run across any problems that are faster solved via that medium.)
(In reply to comment #11) > to compile LO from source, can you please produce a build with attached > debug3.5.patch applied? I did the build. > This should produce a number of debug output lines prefixed with > "WinInetBackend" when opening "Tools - Options... - Internet - Proxy" (via > OutputDebugString, so should be visible when running within WinDbg, or > profiling from depends.exe, etc.). > If you can make available that debug output, that should help us track down > this problem. Any instructions how to setup console debug output on Windows? When running this build I do not see anything like that. I used --enable-debug to build it.
(In reply to comment #15) > (In reply to comment #11) > > This should produce a number of debug output lines prefixed with > > "WinInetBackend" when opening "Tools - Options... - Internet - Proxy" (via > > OutputDebugString, so should be visible when running within WinDbg, or > > profiling from depends.exe, etc.). > > If you can make available that debug output, that should help us track down > > this problem. > > Any instructions how to setup console debug output on Windows? When running > this build I do not see anything like that. I used --enable-debug to build it. The output does not go to stdout/stderr (aka "console"), but is instead handed to Windows' OutputDebugString function. At least when attached to the soffice.bin process via a debugger, this output should be made available via that debugger. (For example, I tested this with the freely available depends.exe, <http://www.dependencywalker.com/>, loading soffice.exe into it and then "Profile - Start Profiling...", taking care that "Log debug output messages." and "Automatically open and profile child processes." are both checked, should start soffice.exe, which in turn starts soffice.bin, for which depends.exe then automatically opens a new sub-window, where the relevant debug output should appear in the bottom pane, along with other logging messages. If only Windows made debug output available in a straightforward way...)
OMG. I'll try to dig into this... BTW: there is no logging output into txt file in LibreOffice for Windows?
(In reply to comment #16) > If only Windows made debug output available in a straightforward way... Seems possible. I got following debug output using DebugView application from http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx Click on Tools>Settings>Options>Proxy: 1st run: 00000001 0.00000000 [5112] WinInetBackend A 759F0000 00000002 0.00007052 [5112] WinInetBackend B 759F6F21 00000003 0.01316426 [5112] WinInetBackend C 0 14 0 00000004 0.01324074 [5112] WinInetBackend D 0 14 0 6F0C82FD 00000028 2nd run: 00000001 0.00000000 [2960] WinInetBackend A 759F0000 00000002 0.00002450 [2960] WinInetBackend B 759F6F21 00000003 0.01467592 [2960] WinInetBackend C 0 14 0 00000004 0.01472293 [2960] WinInetBackend D 0 14 0 737419A0 28A6816B
Created attachment 62785 [details] Bug 47044 - Dependency Walker session with patched wininetbe1.uno.dll Dependency Walker session with patched wininetbe1.uno.dll. Debug output: WinInetBackend A 759F0000 WinInetBackend B 759F6F21 WinInetBackend C 0 14 0 WinInetBackend D 0 14 0 732A19A0 39244C3C
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0dded0d18a5945ed5a38623068ba7aa93da39df0 fdo#47044: Adapt to different Windows versions' InternetQueryOption behavior
@bfoman: Thanks for providing those logs. Looks like various Windows versions have subtly different behavior wrt. InternetQueryOption. I would hope that the patch linked from comment 20 fixes the problem for you, but cannot be completely sure, as I could not reproduce your original problem. Can you please try a build with that patch linked from comment 20, to see whether it really solves the problem for you? If you can announce success, I would see to get that fix backported to 3.5 and 3.6. Thanks.
(In reply to comment #21) > Can you please try a build with that patch linked from comment 20, to see > whether it really solves the problem for you? Will try on monday.
Tested and seems like proxy problem is gone. Also I can't reproduce issues reported in bug 38932 and bug 43616, where bt gave the same source section as crash initiator.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4c07fd7f899b75edd61aa0d16c0f3dff0ebb94ad&g=libreoffice-3-6 fdo#47044: Adapt to different Windows versions' InternetQueryOption behavior It will be available in LibreOffice 3.6.
*** Bug 38932 has been marked as a duplicate of this bug. ***
*** Bug 49903 has been marked as a duplicate of this bug. ***
merged to libreoffice-3-5 and closing :-)
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a1555ee046fcf1fe9e49e8b6820316a66046698a&g=libreoffice-3-5 fdo#47044: Adapt to different Windows versions' InternetQueryOption behavior It will be available in LibreOffice 3.5.5.
We need exact and correct target information for automated lists in Wiki and LibO Web Site.