Strange behavior in debugging of bug #5245, looking for comments

[Alex Villací­s Lasso]

Robert Shearman wrote:
> Alex Villací­s Lasso wrote:
>
>> Last weekend, I was trying to trace down bug #5245 (Run-Time error 
>> '6' overflow in terragen). With current CVS, the bug manifests itself 
>> with an "Overflow" dialog when starting up Terragen. However, this 
>> bug does *not* go away with a native oleaut32.dll (taken from win98), 
>> so this does not seem like an OLE bug. When running the program with 
>> the debugger, the underlying exception trapped before displaying the 
>> dialog reads "inexact float result", with a backtrace that comes out 
>> of the bowels of msvbvm60.dll (weird - NOT inside Terragen.exe, and 
>> NOT inside Terragen.dll). However, if the user types "pass" at the 
>> debugger prompt, the dialog box does not appear, and the program 
>> continues "normally". The exception occurs again whenever a File Open 
>> dialog is dismissed, and again, typing "pass" lets the program run 
>> normally.
>>
>> Several questions:
>> - Can programs that execute floating-point instructions get the 
>> "inexact float result" exception without any explicit setup, or do 
>> they have to call some API in order to enable this notification? If 
>> so, is it described in MSDN?
>
>
> I believe it is an exception code raised by VB itself, not the result 
> of a floating point operation. I've seen it before and it usually 
> means that something unexpected happened under the covers in the VB 
> runtime. However, I would have expected it to be a bug inside 
> oleaut32, but that appears not to be the case here. Have you tried 
> running with native ole32 and rpcrt4 as well to see if the bug 
> disappears?
>
I will try that when I get home. I remember that I even tried 
disassembling the code a few instructions before the addresses indicated 
in the stack trace, and I saw a FIMUL 0x0(%esi) as the source of the 
exception, in the code of msvbvm60.dll.
>> - Is the described behavior normal for the "pass" command? I was 
>> expecting the command to make the app show the Overflow dialog and 
>> then exit.
>
>
> I don't think so. It should have the same behaviour as when running.
>

Is this, therefore, a bug in the debugger?


Alex Villacís Lasso