Strange behavior in debugging of bug #5245, looking for comments
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? - 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. Alex Villacís Lasso
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?
- 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. -- Rob Shearman
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
Alex Villacís Lasso <a_villacis <at> palosanto.com> writes:
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),
Isn't this just a bug in msvcrt? WINEDLLOVERRIDES="msvrt=n" wine Terragen.exe works fine
Louis Lenders wrote:
Alex Villacís Lasso <a_villacis <at> palosanto.com> writes:
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),
Isn't this just a bug in msvcrt? WINEDLLOVERRIDES="msvrt=n" wine Terragen.exe works fine
Confirmed, using native MSVCRT.DLL from Windows 98 "fixes" the bug. Now there is somewhere to look. Possibly the floating point behavior of wine's msvcrt.dll (math.c) differs from native, or else some flags are modified and not restored correctly. Need more tests to pinpoint the root cause (_matherr() ??). Alex Villacís Lasso
participants (3)
-
Alex Villacís Lasso -
Louis Lenders -
Robert Shearman