[Rd] Rgui.exe plot device "Save as" crash (PR#9237)
murdoch at stats.uwo.ca
Tue Sep 19 20:28:04 CEST 2006
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
> 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
> (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
> 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
> *** ERROR: Symbol file could not be found. Defaulted to export symbols
> for C:\WINDOWS\system32\SHELL32.dll -
> 7ca5158e 8b08 mov ecx,dword ptr [eax]
> 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.
More information about the R-devel