Re: [Rd] Rgui.exe plot device Save as crash (PR#9237)
On 9/19/2006 2:15 PM, Michael Toews wrote: I was guessing that this bug would be difficult to trace, I just wanted to document its presence. It is not critical, and can be easily be avoided by: - Saving in Jpeg format; or - Not saving to the Desktop (unless navigated from C:\Documents and Settings\etc.) I'm not convinced that this bug is related to Adobe (as mentioned in Followup 1) .. my example uses PDF, but the same bug occurs when using Png, and others (except Jpeg!?). I really don't know where to go to start looking for this. It would be nice if we had something like valgrind for Windows, but we don't. Regarding valgrind (or other memory debuggers): I'm not a Windows programmer, but would WinDbg be helpful for debugging this? I tried this (free download from MS), and it shows plenty of debugging info, such as values of registers, and the sequences of assembly operators on the CPU, etc. When I open Rgui.exe, it shows all sorts of modules loading when the Save as dialog appears, and when Tooltips are triggered; such as: PDFShell.dll (from Acrobat 7.0), esriShellExt.dll (from ArcGIS), and various *.so files from TortoiseSVN\iconv. The crash occurs, and WinDbg prints: (934.ba8): Access violation - code c005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=049c2038 ebx= ecx=0486f1d4 edx=0486f1cc esi=0486f3e0 edi=000aa0ec eip=7ca5158e esp=0486f134 ebp=0486f37c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=00010246 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\SHELL32.dll - SHELL32!SHCreateQueryCancelAutoPlayMoniker+0xf8a8: 7ca5158e 8b08mov ecx,dword ptr [eax] ds:0023:049c2038= and when I press Go in WinDbg, the instruction/error repeats ad nauseam (with the 'efl' register flipping between 0246 and 00010246; hence the infinite loop). I didn't load the symbols file (I'm not sure what this is -- WinDbg is new territory for me today), but I would guess this could make the debugging output more meaningful. My first impression of WinDbg is that it can be useful for this situation (and others). I got a stack trace from Dr MinGW, and it also reported SHCreateQueryCancelAutoPlayMoniker as the most recent function call before the crash, but the stack trace never made it out of Windows DLLs, or really gave a hint what was the real cause. I think this is probably an R bug (some structure getting messed up before asking for the file dialog) because I can't trigger it from other applications, but it might be a Windows bug, a MinGW run-time bug, or a MSVCRT bug, and it's certainly not clear to me how to determine which. I used to have a program called BoundsChecker that could watch a running program and detect when it wrote outside its own area, or made API calls with bad parameters: it was very useful. However, I don't think it exists any more, and it almost certainly never did for the MinGW compiler we use. I don't think there's any equivalent product for MinGW. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rgui.exe plot device Save as crash (PR#9237)
Full_Name: Michael Toews Version: 2.3.1 OS: WindowsXP Home/Proffesional SP2 Submission from: (NULL) (142.58.206.114) Hi, I have a bug that I can reproduce on two different MS Windows platforms (1:AMD64x2/WinXP SP2 Home; 2:P4/WinXP SP2 Prof.) which is triggered by the Save as dialog when saving a plot from a Windows device onto the Desktop. This bug is difficult to reproduce, but here are some instructions to attempt a crash: 1) Start R from Start menu 2) Plot something simple, such as plot(1:5) 3) Choose File Save as PDF 4) In the dialog, click the Save in: drop-down menu at the top, and select Desktop 5) Type boohoo in the File name: field, and click Save 6) Repeat steps 3 and 4, but try to not hover the mouse over any files or window controls, except for boohoo.pdf (although this isn't always the case). If you don't crash, repeat steps 3 to 5 again until a crash. 7) *crash*; Windows will display the default crash dialog; Rgui.exe will appear in the Windows Task Manager (ctrl-alt-del in Processes tab) using about 0 of CPU. 8) Click Don't Send from the dialog 9) Observe that Rgui.exe is now using all available CPU resources for that thread (this is about 50 for Hyper-threading-enabled or dual-core CPUs). It is probably in an infinite loop. 10) Choose Rgui.exe from the Processes in Windows Task Manager, and click End Process. Now your system will be stable, and you can repeat the bug, if you wish. Here are some things that do _not_ affect the outcome: - Presence or absence of a custom .Rprofile in C:\Program Files\R\R-2.3.1, or Rconsole in My Documents - The use of a different file name in step 5; I have also tried tmp and rat a tat tat, so spaces don't seem to matter - The complexity of the plot - Active or inactive Windows devices - MDI or SDI modes for GUI Here are some things that _do_ affect the outcome: - No crash if you Save as any of the Jpeg options, but crash for all of the other formats (Metafile, Postscript, etc.) - No crash if in other folder, such as My Documents; this crash seems to happen only in the Desktop folder when accessed through the drop-down list at the top or the button on the left-hand side (oddly enough, when navigating an absolute path from C:\Documents and Settings\etc..\Desktop, there is no crash) - In the Save as dialog, if you navigate to the Desktop folder by selecting the button on the left-hand side of the dialog (rather than in the Save in: drop-down field as indicated in step 4), the crash does _not_ trigger the default Microsoft crash dialog, and Rgui.exe silently crashes (disappears), but remains as an active process, using ~ 50% of CPU resources, and requires a manual End Process. - If Debug (if available) or Send Report [to Microsoft] are pressed in the crash dialog, the Rgui.exe process ends normally, and no manual End Process is required. Sorry if this seems TooMuchAtOnce, but it is all the same bug with lots of details. My guess is it has something to do with the Tooltip from the Windows system Save as dialog, which suggests there is a bug in R's implementation of the system Save as dialog. As well, it appears to have problems with the Desktop folder when navigated from the convenient Desktop links (either from the upper drop-down list or left-hand button) in the Save dialog. I don't have access to a pre-compiled Win32 EXE of the the R 2.4.0 alpha releases, otherwise I would try to trigger this bug on the upcoming release. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgui.exe plot device Save as crash (PR#9237)
On 9/18/2006 8:32 PM, [EMAIL PROTECTED] wrote: Full_Name: Michael Toews Version: 2.3.1 OS: WindowsXP Home/Proffesional SP2 Submission from: (NULL) (142.58.206.114) Hi, I have a bug that I can reproduce on two different MS Windows platforms (1:AMD64x2/WinXP SP2 Home; 2:P4/WinXP SP2 Prof.) which is triggered by the Save as dialog when saving a plot from a Windows device onto the Desktop. This bug is difficult to reproduce, but here are some instructions to attempt a crash: 1) Start R from Start menu 2) Plot something simple, such as plot(1:5) 3) Choose File Save as PDF 4) In the dialog, click the Save in: drop-down menu at the top, and select Desktop 5) Type boohoo in the File name: field, and click Save 6) Repeat steps 3 and 4, but try to not hover the mouse over any files or window controls, except for boohoo.pdf (although this isn't always the case). If you don't crash, repeat steps 3 to 5 again until a crash. 7) *crash*; Windows will display the default crash dialog; Rgui.exe will appear in the Windows Task Manager (ctrl-alt-del in Processes tab) using about 0 of CPU. Thanks for the detailed instructions. I can reproduce this in 2.3.1, and a fairly recent (but not today's) R-patched build. I'm just building a current Alpha build to test it there. I'm not sure it's something we'll be able to fix: tooltips are very complicated things, involving tons of DLLs outside of R. This could be an Adobe bug (since Acrobat might be involved in producing a tooltip for a PDF), a Windows bug, or something completely unrelated that just happens to be hooked into Explorer. The fact that we can both see it suggests it's either in R or Windows, though. 8) Click Don't Send from the dialog 9) Observe that Rgui.exe is now using all available CPU resources for that thread (this is about 50 for Hyper-threading-enabled or dual-core CPUs). It is probably in an infinite loop. 10) Choose Rgui.exe from the Processes in Windows Task Manager, and click End Process. Now your system will be stable, and you can repeat the bug, if you wish. Here are some things that do _not_ affect the outcome: - Presence or absence of a custom .Rprofile in C:\Program Files\R\R-2.3.1, or Rconsole in My Documents - The use of a different file name in step 5; I have also tried tmp and rat a tat tat, so spaces don't seem to matter - The complexity of the plot - Active or inactive Windows devices - MDI or SDI modes for GUI Here are some things that _do_ affect the outcome: - No crash if you Save as any of the Jpeg options, but crash for all of the other formats (Metafile, Postscript, etc.) - No crash if in other folder, such as My Documents; this crash seems to happen only in the Desktop folder when accessed through the drop-down list at the top or the button on the left-hand side (oddly enough, when navigating an absolute path from C:\Documents and Settings\etc..\Desktop, there is no crash) - In the Save as dialog, if you navigate to the Desktop folder by selecting the button on the left-hand side of the dialog (rather than in the Save in: drop-down field as indicated in step 4), the crash does _not_ trigger the default Microsoft crash dialog, and Rgui.exe silently crashes (disappears), but remains as an active process, using ~ 50% of CPU resources, and requires a manual End Process. - If Debug (if available) or Send Report [to Microsoft] are pressed in the crash dialog, the Rgui.exe process ends normally, and no manual End Process is required. Sorry if this seems TooMuchAtOnce, but it is all the same bug with lots of details. My guess is it has something to do with the Tooltip from the Windows system Save as dialog, which suggests there is a bug in R's implementation of the system Save as dialog. As well, it appears to have problems with the Desktop folder when navigated from the convenient Desktop links (either from the upper drop-down list or left-hand button) in the Save dialog. I don't have access to a pre-compiled Win32 EXE of the the R 2.4.0 alpha releases, otherwise I would try to trigger this bug on the upcoming release. You can download (approximately) daily builds from cran.r-project.org/bin/windows/base/rtest.html. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgui.exe plot device Save as crash (PR#9237)
On 9/18/2006 9:39 PM, [EMAIL PROTECTED] wrote: On 9/18/2006 8:32 PM, [EMAIL PROTECTED] wrote: Full_Name: Michael Toews Version: 2.3.1 OS: WindowsXP Home/Proffesional SP2 Submission from: (NULL) (142.58.206.114) Hi, I have a bug that I can reproduce on two different MS Windows platforms (1:AMD64x2/WinXP SP2 Home; 2:P4/WinXP SP2 Prof.) which is triggered by the Save as dialog when saving a plot from a Windows device onto the Desktop. This bug is difficult to reproduce, but here are some instructions to attempt a crash: 1) Start R from Start menu 2) Plot something simple, such as plot(1:5) 3) Choose File Save as PDF 4) In the dialog, click the Save in: drop-down menu at the top, and select Desktop 5) Type boohoo in the File name: field, and click Save 6) Repeat steps 3 and 4, but try to not hover the mouse over any files or window controls, except for boohoo.pdf (although this isn't always the case). If you don't crash, repeat steps 3 to 5 again until a crash. 7) *crash*; Windows will display the default crash dialog; Rgui.exe will appear in the Windows Task Manager (ctrl-alt-del in Processes tab) using about 0 of CPU. Thanks for the detailed instructions. I can reproduce this in 2.3.1, and a fairly recent (but not today's) R-patched build. I'm just building a current Alpha build to test it there. I do see the crash in R version 2.4.0 alpha (2006-09-17 r39373), with this stack dump: Call stack: 7CA5158E SHELL32.dll:7CA5158E SHCreateQueryCancelAutoPlayMoniker 7CB2FE26 SHELL32.dll:7CB2FE26 CallCPLEntry16 7CB2FF6A SHELL32.dll:7CB2FF6A CallCPLEntry16 7CB295B5 SHELL32.dll:7CB295B5 Ordinal211 7C9F208D SHELL32.dll:7C9F208D ILFindChild 75F81B9A browseui.dll:75F81B9A Ordinal113 77F69498 SHLWAPI.dll:77F69498 Ordinal120 7C927545 ntdll.dll:7C927545 RtlUpcaseUnicodeString 7C927583 ntdll.dll:7C927583 RtlUpcaseUnicodeString 7C927645 ntdll.dll:7C927645 RtlUpcaseUnicodeString 7C92761C ntdll.dll:7C92761C RtlUpcaseUnicodeString 7C80B683 kernel32.dll:7C80B683 GetModuleFileNameA I really don't know where to go to start looking for this. It would be nice if we had something like valgrind for Windows, but we don't. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
