R devel - Sep 2006 - 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.

On 9/18/2006 8:32 PM, mwtoews at sfu.ca 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

On 9/18/2006 9:39 PM, murdoch at stats.uwo.ca wrote:
> On 9/18/2006 8:32 PM, mwtoews at sfu.ca 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

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 c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=049c2038 ebx=00000000 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=0000             
efl=00010246
*** ERROR: Symbol file could not be found.  Defaulted to export symbols 
for C:\WINDOWS\system32\SHELL32.dll -
SHELL32!SHCreateQueryCancelAutoPlayMoniker+0xf8a8:
7ca5158e 8b08            mov     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 00000246 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).
+mt

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 c0000005 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> eax=049c2038 ebx=00000000 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=0000             
> efl=00010246
> *** ERROR: Symbol file could not be found.  Defaulted to export symbols 
> for C:\WINDOWS\system32\SHELL32.dll -
> SHELL32!SHCreateQueryCancelAutoPlayMoniker+0xf8a8:
> 7ca5158e 8b08            mov     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 00000246 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