| Groups | Blog | Home |
vb.net upgrade : Error handling doesn't work when I ugrade to VB .NET 2003
I've been able to replicate and demonstrate the problem. See the revised http://www.standards.com/temporary/OutOfStackSpace.html. I am now trying to determine whether the same behavior is seen with VB .NET. There are no upgrade warnings when upgrading to VB .NET 2003, however, I do have to change the Currency data type to Long for the purposes of the QueryPerformanceCounter API. I don't know why this is necessary, but it is irrelevant to the issue I'm addressing. As you can see from my OutOfStackSpace.html document, a stack overflow error should occur with a sample size of 6976. This is expected and the program is designed to trap the error and continue. With VB .NET, the stack overflow occurs at a larger sample size of 8908. However, when the error occurs, my error handlers are ignored. What do I need to do to trap the errors? -- http://www.standards.com/; See Howard Kaikow's web site.
[quoted text, click to view]
"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:%23HFUATv8DHA.2672@TK2MSFTNGP10.phx.gbl... > Howard, > > * "Howard Kaikow" <kaikow@standards.com> scripsit: > > See the revised http://www.standards.com/temporary/OutOfStackSpace.html. > > > > I am now trying to determine whether the same behavior is seen with VB ..NET. > > > > There are no upgrade warnings when upgrading to VB .NET 2003, however, I do > > have to change the Currency data type to Long for the purposes of the > > QueryPerformanceCounter API. I don't know why this is necessary, but it is > > irrelevant to the issue I'm addressing. > > You have to use 'Long' because the funktion looks like this in C++: > > \\\ > BOOL QueryPerformanceCounter( > LARGE_INTEGER *lpPerformanceCount // counter value Yes, but it's the same API that is used by VB 6. The implication is that VB .NET passes Decimal to an API differently than VB 6 passes Currency to the API. [quoted text, click to view] > > With VB .NET, the stack overflow occurs at a larger sample size of 8908. > > However, when the error occurs, my error handlers are ignored. > > If I find enough time, I'll have a closer look at it. Thanx. I found something that mentioned that VB .NET splits its exceptions into classes, in particular, Application and System exceptions are in different classes, so maybe the old On Error mechanism cannot detect errors in the new System exception class. Specifically, out of stack space and out of memory are in the System exception class. I need to look further into this.
Howard,
* "Howard Kaikow" <kaikow@standards.com> scripsit: [quoted text, click to view] > See the revised http://www.standards.com/temporary/OutOfStackSpace.html. > > I am now trying to determine whether the same behavior is seen with VB .NET. > > There are no upgrade warnings when upgrading to VB .NET 2003, however, I do > have to change the Currency data type to Long for the purposes of the > QueryPerformanceCounter API. I don't know why this is necessary, but it is > irrelevant to the issue I'm addressing. You have to use 'Long' because the funktion looks like this in C++: \\\ BOOL QueryPerformanceCounter( LARGE_INTEGER *lpPerformanceCount // counter value ); /// [quoted text, click to view] > With VB .NET, the stack overflow occurs at a larger sample size of 8908. > However, when the error occurs, my error handlers are ignored. If I find enough time, I'll have a closer look at it. -- Herfried K. Wagner [MVP]
Howard,
[quoted text, click to view] > Yes, but it's the same API that is used by VB 6. Correct, VB.NET's Decimal does not equal VB6's Currency per se. Although> The implication is that VB .NET passes Decimal to an API differently than VB > 6 passes Currency to the API. Decimal is a good replacement for Currency in most cases! VB6's Currency data type uses 8 bytes of memory and can represent numbers with fifteen digits to the left of the decimal point and four to the right, in the range of -922,337,203,685,477.5808 to 922,337,203,685,477.5807. VB.NET's Decimal data type uses 16 bytes of memory and can represent decimal numbers ranging from positive 79,228,162,514,264,337,593,543,950,335 to negative 79,228,162,514,264,337,593,543,950,335. The Decimal value type is appropriate for financial calculations requiring large numbers of significant integral and fractional digits and no round-off errors. It is a scaled fixed point number, the scaling factor is implicitly the number 10, raised to an exponent ranging from 0 to 28. The QueryPerformanceCounter returns an 8 byte number, hence in VB6 you used Currency as that is the closest 8 byte number supported. In VB.NET you use Long, which is exactly what QueryPerformanceCounter is returning! If I get time tomorrow I will look at the stack problem. Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:OPknXYw8DHA.2576@TK2MSFTNGP11.phx.gbl... > "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message > news:%23HFUATv8DHA.2672@TK2MSFTNGP10.phx.gbl... > > Howard, > > > > * "Howard Kaikow" <kaikow@standards.com> scripsit: > > > See the revised http://www.standards.com/temporary/OutOfStackSpace.html. > > > > > > I am now trying to determine whether the same behavior is seen with VB > .NET. > > > > > > There are no upgrade warnings when upgrading to VB .NET 2003, however, I > do > > > have to change the Currency data type to Long for the purposes of the > > > QueryPerformanceCounter API. I don't know why this is necessary, but it > is > > > irrelevant to the issue I'm addressing. > > > > You have to use 'Long' because the funktion looks like this in C++: > > > > \\\ > > BOOL QueryPerformanceCounter( > > LARGE_INTEGER *lpPerformanceCount // counter value > > Yes, but it's the same API that is used by VB 6. > The implication is that VB .NET passes Decimal to an API differently than VB > 6 passes Currency to the API. > > > > With VB .NET, the stack overflow occurs at a larger sample size of 8908. > > > However, when the error occurs, my error handlers are ignored. > > > > If I find enough time, I'll have a closer look at it. > > Thanx. > > I found something that mentioned that VB .NET splits its exceptions into > classes, in particular, Application and System exceptions are in different > classes, so maybe the old On Error mechanism cannot detect errors in the new > System exception class. Specifically, out of stack space and out of memory > are in the System exception class. > > I need to look further into this. > >
Yes, the difference is the internal representation of Currency vis a vis
Decimal. I believe this justifies a warning by the upgrade wizard when changing Currency to Decimal. -- http://www.standards.com/; See Howard Kaikow's web site. [quoted text, click to view] "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message news:O6FrmE48DHA.2524@TK2MSFTNGP11.phx.gbl... > Howard, > > Yes, but it's the same API that is used by VB 6. > > The implication is that VB .NET passes Decimal to an API differently than > VB > > 6 passes Currency to the API. > Correct, VB.NET's Decimal does not equal VB6's Currency per se. Although > Decimal is a good replacement for Currency in most cases! > > VB6's Currency data type uses 8 bytes of memory and can represent numbers > with fifteen digits to the left of the decimal point and four to the right, > in the range of -922,337,203,685,477.5808 to 922,337,203,685,477.5807. > > VB.NET's Decimal data type uses 16 bytes of memory and can represent decimal > numbers ranging from positive 79,228,162,514,264,337,593,543,950,335 to > negative 79,228,162,514,264,337,593,543,950,335. The Decimal value type is > appropriate for financial calculations requiring large numbers of > significant integral and fractional digits and no round-off errors. It is a > scaled fixed point number, the scaling factor is implicitly the number 10, > raised to an exponent ranging from 0 to 28. > > > The QueryPerformanceCounter returns an 8 byte number, hence in VB6 you used > Currency as that is the closest 8 byte number supported. In VB.NET you use > Long, which is exactly what QueryPerformanceCounter is returning! > > > If I get time tomorrow I will look at the stack problem. > > Hope this helps > Jay > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > news:OPknXYw8DHA.2576@TK2MSFTNGP11.phx.gbl... > > "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message > > news:%23HFUATv8DHA.2672@TK2MSFTNGP10.phx.gbl... > > > Howard, > > > > > > * "Howard Kaikow" <kaikow@standards.com> scripsit: > > > > See the revised > http://www.standards.com/temporary/OutOfStackSpace.html. > > > > > > > > I am now trying to determine whether the same behavior is seen with VB > > .NET. > > > > > > > > There are no upgrade warnings when upgrading to VB .NET 2003, however, > I > > do > > > > have to change the Currency data type to Long for the purposes of the > > > > QueryPerformanceCounter API. I don't know why this is necessary, but > it > > is > > > > irrelevant to the issue I'm addressing. > > > > > > You have to use 'Long' because the funktion looks like this in C++: > > > > > > \\\ > > > BOOL QueryPerformanceCounter( > > > LARGE_INTEGER *lpPerformanceCount // counter value > > > > Yes, but it's the same API that is used by VB 6. > > The implication is that VB .NET passes Decimal to an API differently than > VB > > 6 passes Currency to the API. > > > > > > With VB .NET, the stack overflow occurs at a larger sample size of > 8908. > > > > However, when the error occurs, my error handlers are ignored. > > > > > > If I find enough time, I'll have a closer look at it. > > > > Thanx. > > > > I found something that mentioned that VB .NET splits its exceptions into > > classes, in particular, Application and System exceptions are in different > > classes, so maybe the old On Error mechanism cannot detect errors in the > new > > System exception class. Specifically, out of stack space and out of memory > > are in the System exception class. > > > > I need to look further into this. > > > > > >
Howard,
I guess it depends on your perspective. I would not expect a warning on converting Currency To Decimal. As the Upgrade Wizard is doing it "correct" for most cases, the only case (I can think of) where it may cause a problem being the Declare statement. I would personally make a point to verify all my Declare statements any way, so a warning about Currency to Decimal would not help (me). A Warning about a Declare statement may help... Before you attempted to upgrade your VB6 project, did you use the Upgrade Advisor? http://msdn.microsoft.com/vbasic/downloads/codeadvisor/default.aspx The Upgrade Advisor will allow you to modify your VB6 project, so that the upgrade wizard does a better job of upgrading it. Don't remember specifically if it does any thing for Currency vs Decimal... BTW: Which version of VS.NET did you use? Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:%23vTNWC58DHA.1428@TK2MSFTNGP12.phx.gbl... > Yes, the difference is the internal representation of Currency vis a vis > Decimal. > I believe this justifies a warning by the upgrade wizard when changing > Currency to Decimal. > > -- > http://www.standards.com/; See Howard Kaikow's web site. > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > news:O6FrmE48DHA.2524@TK2MSFTNGP11.phx.gbl... > > Howard, > > > Yes, but it's the same API that is used by VB 6. > > > The implication is that VB .NET passes Decimal to an API differently > than > > VB > > > 6 passes Currency to the API. > > Correct, VB.NET's Decimal does not equal VB6's Currency per se. Although > > Decimal is a good replacement for Currency in most cases! > > > > VB6's Currency data type uses 8 bytes of memory and can represent numbers > > with fifteen digits to the left of the decimal point and four to the > right, > > in the range of -922,337,203,685,477.5808 to 922,337,203,685,477.5807. > > > > VB.NET's Decimal data type uses 16 bytes of memory and can represent > decimal > > numbers ranging from positive 79,228,162,514,264,337,593,543,950,335 to > > negative 79,228,162,514,264,337,593,543,950,335. The Decimal value type is > > appropriate for financial calculations requiring large numbers of > > significant integral and fractional digits and no round-off errors. It is > a > > scaled fixed point number, the scaling factor is implicitly the number 10, > > raised to an exponent ranging from 0 to 28. > > > > > > The QueryPerformanceCounter returns an 8 byte number, hence in VB6 you > used > > Currency as that is the closest 8 byte number supported. In VB.NET you use > > Long, which is exactly what QueryPerformanceCounter is returning! > > > > > > If I get time tomorrow I will look at the stack problem. > > > > Hope this helps > > Jay > > > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > news:OPknXYw8DHA.2576@TK2MSFTNGP11.phx.gbl... > > > "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message > > > news:%23HFUATv8DHA.2672@TK2MSFTNGP10.phx.gbl... > > > > Howard, > > > > > > > > * "Howard Kaikow" <kaikow@standards.com> scripsit: > > > > > See the revised > > http://www.standards.com/temporary/OutOfStackSpace.html. > > > > > > > > > > I am now trying to determine whether the same behavior is seen with > VB > > > .NET. > > > > > > > > > > There are no upgrade warnings when upgrading to VB .NET 2003, > however, > > I > > > do > > > > > have to change the Currency data type to Long for the purposes of > the > > > > > QueryPerformanceCounter API. I don't know why this is necessary, but > > it > > > is > > > > > irrelevant to the issue I'm addressing. > > > > > > > > You have to use 'Long' because the funktion looks like this in C++: > > > > > > > > \\\ > > > > BOOL QueryPerformanceCounter( > > > > LARGE_INTEGER *lpPerformanceCount // counter value > > > > > > Yes, but it's the same API that is used by VB 6. > > > The implication is that VB .NET passes Decimal to an API differently > than > > VB > > > 6 passes Currency to the API. > > > > > > > > With VB .NET, the stack overflow occurs at a larger sample size of > > 8908. > > > > > However, when the error occurs, my error handlers are ignored. > > > > > > > > If I find enough time, I'll have a closer look at it. > > > > > > Thanx. > > > > > > I found something that mentioned that VB .NET splits its exceptions > into > > > classes, in particular, Application and System exceptions are in > different > > > classes, so maybe the old On Error mechanism cannot detect errors in the > > new > > > System exception class. Specifically, out of stack space and out of > memory > > > are in the System exception class. > > > > > > I need to look further into this. > > > > > > > > > > > >
[quoted text, click to view]
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message news:Oh6IO%2388DHA.2832@tk2msftngp13.phx.gbl... > Howard, > I guess it depends on your perspective. Mine is nasty. [quoted text, click to view] > I would not expect a warning on converting Currency To Decimal. As the > Upgrade Wizard is doing it "correct" for most cases, the only case (I can > think of) where it may cause a problem being the Declare statement. I would > personally make a point to verify all my Declare statements any way, so a > warning about Currency to Decimal would not help (me). A Warning about a > Declare statement may help... The problem with the QueryPerformance stuff is that such conversion failures slip by unnoticed as most software using the QP API would test for whether a High Resolution timer is avaialable and, if not, just silently use GetTickCount. Code appears to continue to work, but uses less accurate timing. [quoted text, click to view] > Before you attempted to upgrade your VB6 project, did you use the Upgrade > Advisor? > > http://msdn.microsoft.com/vbasic/downloads/codeadvisor/default.aspx I downloaded the critter last year, but do not believe in such tools. If such a tool exists, then MSFT could just as well have a white paper describing ALL the issues addressed by the Upgrade Advisor. [quoted text, click to view] > BTW: Which version of VS.NET did you use? 2002 and 2003.
Howard,
[quoted text, click to view] > The problem with the QueryPerformance stuff is that such conversion Are you suggesting that QueryPerformance itself should have an explicitfailures > slip by unnoticed as most software using the QP API would test for whether a > High Resolution timer is avaialable and, if not, just silently use > GetTickCount. Code appears to continue to work, but uses less accurate > timing. warning? If so you can use the Code Advisor from VB6 to warn you before the upgrade, or you could use one of the many Code Critic & Code Analyzers after you upgrade. A Code Critic is a utility that looks at your code and gives you feedback on what you should change to improve it. Such as http://www.fmsinc.com/reviews/tnanalyzer/sd1202.htm As both the Code Advisor & most Code Critics are customizable that you can add your own warnings. Alternatively you could check with Aivosto, http://www.aivosto.com/, the makes of the Upgrade Wizard, to see if their version of the Upgrade Wizard supports adding custom warnings. BTW: Whidbey is introducing a StopWatch class that encapsulates the QueryPerformance stuff verses GetTickCount stuff. http://longhorn.msdn.microsoft.com/?//longhorn.msdn.microsoft.com/lhsdk/ref/ns/system.diagnostics/c/stopwatch/stopwatch.aspx Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:OxXTGS98DHA.400@tk2msftngp13.phx.gbl... > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > news:Oh6IO%2388DHA.2832@tk2msftngp13.phx.gbl... > > Howard, > > I guess it depends on your perspective. > > Mine is nasty. > > > I would not expect a warning on converting Currency To Decimal. As the > > Upgrade Wizard is doing it "correct" for most cases, the only case (I can > > think of) where it may cause a problem being the Declare statement. I > would > > personally make a point to verify all my Declare statements any way, so a > > warning about Currency to Decimal would not help (me). A Warning about a > > Declare statement may help... > > The problem with the QueryPerformance stuff is that such conversion failures > slip by unnoticed as most software using the QP API would test for whether a > High Resolution timer is avaialable and, if not, just silently use > GetTickCount. Code appears to continue to work, but uses less accurate > timing. > > > Before you attempted to upgrade your VB6 project, did you use the Upgrade > > Advisor? > > > > http://msdn.microsoft.com/vbasic/downloads/codeadvisor/default.aspx > > I downloaded the critter last year, but do not believe in such tools. > If such a tool exists, then MSFT could just as well have a white paper > describing ALL the issues addressed by the Upgrade Advisor. > > > BTW: Which version of VS.NET did you use? > > 2002 and 2003. > >
Howard,
[quoted text, click to view] > The replacement of Currency by Decimal deserves a warning, perhaps only in If the Upgrade Wizard included that specific warning, I suspect there are> Declares. > After all, the upgrade is INTENTIONALLY breaking the statement. hundreds if not thousands of other specific warnings that should be included. The problem with including warnings at this level of detail is, that it will take forever for Microsoft to test & release the product. Also as I suggested I would not want that warning to show up when I upgrade my projects. (I'm not saying that there is not value in your specific warning). Which is were the Code Advisor, Code Critic, and Code Analyzers that are customizable I find more value in... (in this regard). Just a thought Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:u$0cxL$8DHA.2856@TK2MSFTNGP10.phx.gbl... > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > news:%23c%23NNA%238DHA.2404@TK2MSFTNGP11.phx.gbl... > > Howard, > > > The problem with the QueryPerformance stuff is that such conversion > > failures > > > slip by unnoticed as most software using the QP API would test for > whether > > a > > > High Resolution timer is avaialable and, if not, just silently use > > > GetTickCount. Code appears to continue to work, but uses less accurate > > > timing. > > Are you suggesting that QueryPerformance itself should have an explicit > > warning? > > No. > > The replacement of Currency by Decimal deserves a warning, perhaps only in > Declares. > After all, the upgrade is INTENTIONALLY breaking the statement. > > > If so you can use the Code Advisor from VB6 to warn you before the > upgrade, > > or you could use one of the many Code Critic & Code Analyzers after you > > upgrade. > > > > A Code Critic is a utility that looks at your code and gives you feedback > on > > what you should change to improve it. > > > > Such as > > http://www.fmsinc.com/reviews/tnanalyzer/sd1202.htm > > I may take a look. > >
[quoted text, click to view]
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message news:%23c%23NNA%238DHA.2404@TK2MSFTNGP11.phx.gbl... > Howard, > > The problem with the QueryPerformance stuff is that such conversion > failures > > slip by unnoticed as most software using the QP API would test for whether > a > > High Resolution timer is avaialable and, if not, just silently use > > GetTickCount. Code appears to continue to work, but uses less accurate > > timing. > Are you suggesting that QueryPerformance itself should have an explicit > warning? No. The replacement of Currency by Decimal deserves a warning, perhaps only in Declares. After all, the upgrade is INTENTIONALLY breaking the statement. [quoted text, click to view] > If so you can use the Code Advisor from VB6 to warn you before the upgrade, > or you could use one of the many Code Critic & Code Analyzers after you > upgrade. > > A Code Critic is a utility that looks at your code and gives you feedback on > what you should change to improve it. > > Such as > http://www.fmsinc.com/reviews/tnanalyzer/sd1202.htm I may take a look.
Howard,
[quoted text, click to view] > What do I need to do to trap the errors? Based on the "Fatal stack overflow error" printed, and the following test.The VB.NET runtime for some reason is deciding to terminate your program, as opposed to allowing you to catch the StackOverflowException that is being thrown by the CLR: In the following (placed in your frmMessages) the StackOverflowException is caught & printed. Public Shared Sub TestRecursion() TestRecursion() End Sub Public Shared Sub Main() Try TestRecursion() Catch ex As Exception Debug.WriteLine(ex, "Main") End Try End Sub It would appear that one or more of the runtime routines that you are calling have decided that we don't need to catch the StackOverflowException... You do realize that the stack overflow is largely caused by a "bug" in one of sort routines, that is not handling a sorted list correctly? If you change DataCreate to create a non-sorted array, the Stack overflow does not occur. Which to me suggests a bug in that specific routine... Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:ecW%237Tu8DHA.452@TK2MSFTNGP11.phx.gbl... > In a VB newsgroup, I've described an apparent problem with VB 6. > > I've been able to replicate and demonstrate the problem. > > See the revised http://www.standards.com/temporary/OutOfStackSpace.html. > > I am now trying to determine whether the same behavior is seen with VB ..NET. > > There are no upgrade warnings when upgrading to VB .NET 2003, however, I do > have to change the Currency data type to Long for the purposes of the > QueryPerformanceCounter API. I don't know why this is necessary, but it is > irrelevant to the issue I'm addressing. > > As you can see from my OutOfStackSpace.html document, a stack overflow error > should occur with a sample size of 6976. This is expected and the program is > designed to trap the error and continue. > > With VB .NET, the stack overflow occurs at a larger sample size of 8908. > However, when the error occurs, my error handlers are ignored. > > What do I need to do to trap the errors? > > -- > http://www.standards.com/; See Howard Kaikow's web site. > >
Howard,
To continue my last message, it appears to be related to this expression: x = Int((max - min + 1) * Rnd() + min) Replacing the above expression with: Dim rand As New Random x = rand.Next(min, max) The exception handlers (try/catch) will catch the stack overflow! Note I would recommend making the rand variable a module or class level variable, not a function level. Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:ecW%237Tu8DHA.452@TK2MSFTNGP11.phx.gbl... > In a VB newsgroup, I've described an apparent problem with VB 6. > > I've been able to replicate and demonstrate the problem. > > See the revised http://www.standards.com/temporary/OutOfStackSpace.html. > > I am now trying to determine whether the same behavior is seen with VB ..NET. > > There are no upgrade warnings when upgrading to VB .NET 2003, however, I do > have to change the Currency data type to Long for the purposes of the > QueryPerformanceCounter API. I don't know why this is necessary, but it is > irrelevant to the issue I'm addressing. > > As you can see from my OutOfStackSpace.html document, a stack overflow error > should occur with a sample size of 6976. This is expected and the program is > designed to trap the error and continue. > > With VB .NET, the stack overflow occurs at a larger sample size of 8908. > However, when the error occurs, my error handlers are ignored. > > What do I need to do to trap the errors? > > -- > http://www.standards.com/; See Howard Kaikow's web site. > >
[quoted text, click to view]
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message news:e74T%238$8DHA.488@TK2MSFTNGP12.phx.gbl... > Howard, > > What do I need to do to trap the errors? > Based on the "Fatal stack overflow error" printed, and the following test. > The VB.NET runtime for some reason is deciding to terminate your program, as > opposed to allowing you to catch the StackOverflowException that is being > thrown by the CLR: > > In the following (placed in your frmMessages) the StackOverflowException is > caught & printed. > > Public Shared Sub TestRecursion() > TestRecursion() > End Sub > > Public Shared Sub Main() > Try > TestRecursion() > Catch ex As Exception > Debug.WriteLine(ex, "Main") > End Try > End Sub Yes, I can trap the error with separate code too. [quoted text, click to view] > It would appear that one or more of the runtime routines that you are > calling have decided that we don't need to catch the > StackOverflowException... I'm not calling any runtime routines. As I recall, I have eliminated all the On Error goTo -1, On Error GoTo 0 and Err.Clear statements, other than for the two Err.Clear in pDoQuick and the ..Clear in the two error processing subs. Each algorithm test starts with an On Error GoTo Somewhere, which should clear previous errors. I just received a message from someone who was able to replicate the problem and he included the files he used. I've not yet had a chance to look at his files. [quoted text, click to view] > You do realize that the stack overflow is largely caused by a "bug" in one > of sort routines, that is not handling a sorted list correctly? If you > change DataCreate to create a non-sorted array, the Stack overflow does not > occur. Which to me suggests a bug in that specific routine... It's not a bug. One of the characteristics of quick sort is that, the fundamental algorithm poorly handles presorted data and constant data. There are ways to implement quicksort to reduce, but not eliminate the problem. For example, algorithms S7.1, S7.1- and S7.5 are also easily coerced into a stack space error (using a larger sample size, I forget the number), but they have not yet exhibited the subsequent error behavior caused by using algorithm RS/pRS. Since the program is a test of various sorting algorihms, I cannot recode particular algorithms. One of the benefits of the program is going to be to inform folkes of the following. Just because an algorithm is published, in this case, in a quite useful book, does not mean that the algorithm should be used without further investigation. Indeed, there is another algorithm, in an even more widely known book, that is even worse. [quoted text, click to view] > > Hope this helps > Jay > > "Howard Kaikow" <kaikow@standards.com> wrote in message > news:ecW%237Tu8DHA.452@TK2MSFTNGP11.phx.gbl... > > In a VB newsgroup, I've described an apparent problem with VB 6. > > > > I've been able to replicate and demonstrate the problem. > > > > See the revised http://www.standards.com/temporary/OutOfStackSpace.html. > > > > I am now trying to determine whether the same behavior is seen with VB > .NET. > > > > There are no upgrade warnings when upgrading to VB .NET 2003, however, I > do > > have to change the Currency data type to Long for the purposes of the > > QueryPerformanceCounter API. I don't know why this is necessary, but it is > > irrelevant to the issue I'm addressing. > > > > As you can see from my OutOfStackSpace.html document, a stack overflow > error > > should occur with a sample size of 6976. This is expected and the program > is > > designed to trap the error and continue. > > > > With VB .NET, the stack overflow occurs at a larger sample size of 8908. > > However, when the error occurs, my error handlers are ignored. > > > > What do I need to do to trap the errors? > > > > -- > > http://www.standards.com/; See Howard Kaikow's web site. > > > > > >
[quoted text, click to view]
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message news:OCDDmGA9DHA.1428@TK2MSFTNGP12.phx.gbl... > Howard, > To continue my last message, it appears to be related to this expression: > > x = Int((max - min + 1) * Rnd() + min) The problem is caused by the less than robust implementation of the quick sort algorithm, which is causing, according to somebody else who has looked at this, at least 4 times as many levels of recursion as some other algorithms Changing the above statement would not affect this. [quoted text, click to view] > Replacing the above expression with: > > Dim rand As New Random > x = rand.Next(min, max) > > The exception handlers (try/catch) will catch the stack overflow! It would not surprise me that the errors would be caught if I used try instead of on error, but I would consider that to be a bug in VB .NET. I'll try, no pun intended, this later. [quoted text, click to view] > Note I would recommend making the rand variable a module or class level > variable, not a function level. I cannot change the algorithm.
Thanx to Jay, I now see the cause of the problem, definitely a VB .NET bug.
Not only do I need to replace the Rnd function in the RS and pRS algorithms with the native VB .NET Random, I also need to use Try/Catch in the calling sub. Note that I use Rnd in some of the other subs with no problem. So it would appear the particular implementation of quicksort in RS and pRS algorithms is causing recursion so deep that the On Error mechanism is getting munged by some use of Rnd. I replaced all the On Error GoTo statements with Try/Catch and added the Random, then stack error was trapped. -- http://www.standards.com/; See Howard Kaikow's web site. [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:%23ds9NWH9DHA.2168@TK2MSFTNGP12.phx.gbl... > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > news:OCDDmGA9DHA.1428@TK2MSFTNGP12.phx.gbl... > > Howard, > > To continue my last message, it appears to be related to this expression: > > > > x = Int((max - min + 1) * Rnd() + min) > > The problem is caused by the less than robust implementation of the quick > sort algorithm, which is causing, according to somebody else who has looked > at this, at least 4 times as many levels of recursion as some other > algorithms > Changing the above statement would not affect this. > > > Replacing the above expression with: > > > > Dim rand As New Random > > x = rand.Next(min, max) > > > > The exception handlers (try/catch) will catch the stack overflow! > > It would not surprise me that the errors would be caught if I used try > instead of on error, but I would consider that to be a bug in VB .NET. I'll > try, no pun intended, this later. > > > Note I would recommend making the rand variable a module or class level > > variable, not a function level. > > I cannot change the algorithm. > >
Howard,
[quoted text, click to view] > So it would appear the particular implementation of quicksort in RS and pRS > algorithms is causing recursion so deep that the On Error mechanism is > getting munged by some use of Rnd. Both Rnd & Int in TestRecursion in the following was causing the program to terminate. Public Shared Sub TestRecursion() ' Rnd or Int here... TestRecursion() End Sub Public Shared Sub Main() Try TestRecursion() Catch ex As Exception Debug.WriteLine(ex, "Main") End Try End Sub Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:eOgZxGI9DHA.3380@tk2msftngp13.phx.gbl... > Thanx to Jay, I now see the cause of the problem, definitely a VB .NET bug. > > Not only do I need to replace the Rnd function in the RS and pRS algorithms > with the native VB .NET Random, I also need to use Try/Catch in the calling > sub. > > Note that I use Rnd in some of the other subs with no problem. > > So it would appear the particular implementation of quicksort in RS and pRS > algorithms is causing recursion so deep that the On Error mechanism is > getting munged by some use of Rnd. > > I replaced all the On Error GoTo statements with Try/Catch and added the > Random, then stack error was trapped. > > -- > http://www.standards.com/; See Howard Kaikow's web site. > "Howard Kaikow" <kaikow@standards.com> wrote in message > news:%23ds9NWH9DHA.2168@TK2MSFTNGP12.phx.gbl... > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > > news:OCDDmGA9DHA.1428@TK2MSFTNGP12.phx.gbl... > > > Howard, > > > To continue my last message, it appears to be related to this > expression: > > > > > > x = Int((max - min + 1) * Rnd() + min) > > > > The problem is caused by the less than robust implementation of the quick > > sort algorithm, which is causing, according to somebody else who has > looked > > at this, at least 4 times as many levels of recursion as some other > > algorithms > > Changing the above statement would not affect this. > > > > > Replacing the above expression with: > > > > > > Dim rand As New Random > > > x = rand.Next(min, max) > > > > > > The exception handlers (try/catch) will catch the stack overflow! > > > > It would not surprise me that the errors would be caught if I used try > > instead of on error, but I would consider that to be a bug in VB .NET. > I'll > > try, no pun intended, this later. > > > > > Note I would recommend making the rand variable a module or class level > > > variable, not a function level. > > > > I cannot change the algorithm. > > > > > >
Howard,
[quoted text, click to view] > I'm not calling any runtime routines. Yes! you are! I hope you realize that both Rnd, Int are VB.NET runtime routines! [quoted text, click to view] > It's not a bug. Yes! It Is! I am not saying that it is a bug in your implementation of the algorithm, per se. I am saying it is a bug in the algorithm itself. As you stated in your other post. "The problem is caused by the less than robust implementation of the quick sort algorithm, which is causing, according to somebody else who has looked at this, at least 4 times as many levels of recursion as some other algorithms" I'm consider a "less then robust implementation" to be a bug! What's that saying: a rose by any other name is still a rose... Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:%23YNQ6QH9DHA.2576@TK2MSFTNGP09.phx.gbl... > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > news:e74T%238$8DHA.488@TK2MSFTNGP12.phx.gbl... > > Howard, > > > What do I need to do to trap the errors? > > Based on the "Fatal stack overflow error" printed, and the following test. > > The VB.NET runtime for some reason is deciding to terminate your program, > as > > opposed to allowing you to catch the StackOverflowException that is being > > thrown by the CLR: > > > > In the following (placed in your frmMessages) the StackOverflowException > is > > caught & printed. > > > > Public Shared Sub TestRecursion() > > TestRecursion() > > End Sub > > > > Public Shared Sub Main() > > Try > > TestRecursion() > > Catch ex As Exception > > Debug.WriteLine(ex, "Main") > > End Try > > End Sub > > Yes, I can trap the error with separate code too. > > > It would appear that one or more of the runtime routines that you are > > calling have decided that we don't need to catch the > > StackOverflowException... > > I'm not calling any runtime routines. > > As I recall, I have eliminated all the On Error goTo -1, On Error GoTo 0 and > Err.Clear statements, other than for the two Err.Clear in pDoQuick and the > .Clear in the two error processing subs. > > Each algorithm test starts with an On Error GoTo Somewhere, which should > clear previous errors. > > I just received a message from someone who was able to replicate the problem > and he included the files he used. > I've not yet had a chance to look at his files. > > > You do realize that the stack overflow is largely caused by a "bug" in one > > of sort routines, that is not handling a sorted list correctly? If you > > change DataCreate to create a non-sorted array, the Stack overflow does > not > > occur. Which to me suggests a bug in that specific routine... > > It's not a bug. > > One of the characteristics of quick sort is that, the fundamental algorithm > poorly handles presorted data and constant data. > There are ways to implement quicksort to reduce, but not eliminate the > problem. > > For example, algorithms S7.1, S7.1- and S7.5 are also easily coerced into a > stack space error (using a larger sample size, I forget the number), but > they have not yet exhibited the subsequent error behavior caused by using > algorithm RS/pRS. > > Since the program is a test of various sorting algorihms, I cannot recode > particular algorithms. One of the benefits of the program is going to be to > inform folkes of the following. > > Just because an algorithm is published, in this case, in a quite useful > book, does not mean that the algorithm should be used without further > investigation. > > Indeed, there is another algorithm, in an even more widely known book, that > is even worse. > > > > Hope this helps > > Jay > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > news:ecW%237Tu8DHA.452@TK2MSFTNGP11.phx.gbl... > > > In a VB newsgroup, I've described an apparent problem with VB 6. > > > > > > I've been able to replicate and demonstrate the problem. > > > > > > See the revised http://www.standards.com/temporary/OutOfStackSpace.html. > > > > > > I am now trying to determine whether the same behavior is seen with VB > > .NET. > > > > > > There are no upgrade warnings when upgrading to VB .NET 2003, however, I > > do > > > have to change the Currency data type to Long for the purposes of the > > > QueryPerformanceCounter API. I don't know why this is necessary, but it > is > > > irrelevant to the issue I'm addressing. > > > > > > As you can see from my OutOfStackSpace.html document, a stack overflow > > error > > > should occur with a sample size of 6976. This is expected and the > program > > is > > > designed to trap the error and continue. > > > > > > With VB .NET, the stack overflow occurs at a larger sample size of 8908. > > > However, when the error occurs, my error handlers are ignored. > > > > > > What do I need to do to trap the errors? > > > > > > -- > > > http://www.standards.com/; See Howard Kaikow's web site. > > > > > > > > > > > >
Howard,
Unfortunately I believe you are missing the point I am attempting to make! There are *two* bugs going on here: 1. The bug in your code that causes a stack overflow. 2. The bug in VB.NET that does not allow you to catch the above stack overflow. You understandable are only concerned with the second. I am attempting to point out both. Just a thought Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:OkXfpcL9DHA.2404@TK2MSFTNGP11.phx.gbl... > I don't agree that poorly designed code is a bug. > A compiler has to handle any legal program., be it good bad or ugly. > > -- > http://www.standards.com/; See Howard Kaikow's web site. > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > news:uUAVmSJ9DHA.2856@TK2MSFTNGP10.phx.gbl... > > Howard, > > > I'm not calling any runtime routines. > > > > Yes! you are! I hope you realize that both Rnd, Int are VB.NET runtime > > routines! > > > > > It's not a bug. > > > > Yes! It Is! I am not saying that it is a bug in your implementation of the > > algorithm, per se. I am saying it is a bug in the algorithm itself. As you > > stated in your other post. "The problem is caused by the less than robust > > implementation of the quick sort algorithm, which is causing, according to > > somebody else who has looked at this, at least 4 times as many levels of > > recursion as some other algorithms" > > > > I'm consider a "less then robust implementation" to be a bug! > > > > What's that saying: a rose by any other name is still a rose... > > > > Hope this helps > > Jay > > > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > news:%23YNQ6QH9DHA.2576@TK2MSFTNGP09.phx.gbl... > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in > message > > > news:e74T%238$8DHA.488@TK2MSFTNGP12.phx.gbl... > > > > Howard, > > > > > What do I need to do to trap the errors? > > > > Based on the "Fatal stack overflow error" printed, and the following > > test. > > > > The VB.NET runtime for some reason is deciding to terminate your > > program, > > > as > > > > opposed to allowing you to catch the StackOverflowException that is > > being > > > > thrown by the CLR: > > > > > > > > In the following (placed in your frmMessages) the > StackOverflowException > > > is > > > > caught & printed. > > > > > > > > Public Shared Sub TestRecursion() > > > > TestRecursion() > > > > End Sub > > > > > > > > Public Shared Sub Main() > > > > Try > > > > TestRecursion() > > > > Catch ex As Exception > > > > Debug.WriteLine(ex, "Main") > > > > End Try > > > > End Sub > > > > > > Yes, I can trap the error with separate code too. > > > > > > > It would appear that one or more of the runtime routines that you are > > > > calling have decided that we don't need to catch the > > > > StackOverflowException... > > > > > > I'm not calling any runtime routines. > > > > > > As I recall, I have eliminated all the On Error goTo -1, On Error GoTo 0 > > and > > > Err.Clear statements, other than for the two Err.Clear in pDoQuick and > the > > > .Clear in the two error processing subs. > > > > > > Each algorithm test starts with an On Error GoTo Somewhere, which should > > > clear previous errors. > > > > > > I just received a message from someone who was able to replicate the > > problem > > > and he included the files he used. > > > I've not yet had a chance to look at his files. > > > > > > > You do realize that the stack overflow is largely caused by a "bug" in > > one > > > > of sort routines, that is not handling a sorted list correctly? If you > > > > change DataCreate to create a non-sorted array, the Stack overflow > does > > > not > > > > occur. Which to me suggests a bug in that specific routine... > > > > > > It's not a bug. > > > > > > One of the characteristics of quick sort is that, the fundamental > > algorithm > > > poorly handles presorted data and constant data. > > > There are ways to implement quicksort to reduce, but not eliminate the > > > problem. > > > > > > For example, algorithms S7.1, S7.1- and S7.5 are also easily coerced > into > > a > > > stack space error (using a larger sample size, I forget the number), but > > > they have not yet exhibited the subsequent error behavior caused by > using > > > algorithm RS/pRS. > > > > > > Since the program is a test of various sorting algorihms, I cannot > recode > > > particular algorithms. One of the benefits of the program is going to be > > to > > > inform folkes of the following. > > > > > > Just because an algorithm is published, in this case, in a quite useful > > > book, does not mean that the algorithm should be used without further > > > investigation. > > > > > > Indeed, there is another algorithm, in an even more widely known book, > > that > > > is even worse. > > > > > > > > Hope this helps > > > > Jay > > > > > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > > > news:ecW%237Tu8DHA.452@TK2MSFTNGP11.phx.gbl... > > > > > In a VB newsgroup, I've described an apparent problem with VB 6. > > > > > > > > > > I've been able to replicate and demonstrate the problem. > > > > > > > > > > See the revised > > http://www.standards.com/temporary/OutOfStackSpace.html. > > > > > > > > > > I am now trying to determine whether the same behavior is seen with > VB > > > > .NET. > > > > > > > > > > There are no upgrade warnings when upgrading to VB .NET 2003, > however, > > I > > > > do > > > > > have to change the Currency data type to Long for the purposes of > the > > > > > QueryPerformanceCounter API. I don't know why this is necessary, but > > it > > > is > > > > > irrelevant to the issue I'm addressing. > > > > > > > > > > As you can see from my OutOfStackSpace.html document, a stack > overflow > > > > error > > > > > should occur with a sample size of 6976. This is expected and the > > > program > > > > is > > > > > designed to trap the error and continue. > > > > > > > > > > With VB .NET, the stack overflow occurs at a larger sample size of > > 8908. > > > > > However, when the error occurs, my error handlers are ignored. > > > > > > > > > > What do I need to do to trap the errors? > > > > > > > > > > -- > > > > > http://www.standards.com/; See Howard Kaikow's web site. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Howard,
Oh!!! I see Its a FEATURE then! How does that saying go: A rose by any other name is still a rose... If you do not consider unrestricted recursion a bug, then I won't press the matter... Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message
news:%23aYLWwL9DHA.1804@TK2MSFTNGP12.phx.gbl... > The first is NOT a bug, it is by design > > -- > http://www.standards.com/; See Howard Kaikow's web site. > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > news:efzUZvL9DHA.1548@tk2msftngp13.phx.gbl... > > Howard, > > Unfortunately I believe you are missing the point I am attempting to make! > > > > There are *two* bugs going on here: > > 1. The bug in your code that causes a stack overflow. > > > > 2. The bug in VB.NET that does not allow you to catch the above stack > > overflow. > > > > You understandable are only concerned with the second. I am attempting to > > point out both. > > > > Just a thought > > Jay > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > news:OkXfpcL9DHA.2404@TK2MSFTNGP11.phx.gbl... > > > I don't agree that poorly designed code is a bug. > > > A compiler has to handle any legal program., be it good bad or ugly. > > > > > > -- > > > http://www.standards.com/; See Howard Kaikow's web site. > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in > message > > > news:uUAVmSJ9DHA.2856@TK2MSFTNGP10.phx.gbl... > > > > Howard, > > > > > I'm not calling any runtime routines. > > > > > > > > Yes! you are! I hope you realize that both Rnd, Int are VB.NET runtime > > > > routines! > > > > > > > > > It's not a bug. > > > > > > > > Yes! It Is! I am not saying that it is a bug in your implementation of > > the > > > > algorithm, per se. I am saying it is a bug in the algorithm itself. As > > you > > > > stated in your other post. "The problem is caused by the less than > > robust > > > > implementation of the quick sort algorithm, which is causing, > according > > to > > > > somebody else who has looked at this, at least 4 times as many levels > of > > > > recursion as some other algorithms" > > > > > > > > I'm consider a "less then robust implementation" to be a bug! > > > > > > > > What's that saying: a rose by any other name is still a rose... > > > > > > > > Hope this helps > > > > Jay > > > > > > > > > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > > > news:%23YNQ6QH9DHA.2576@TK2MSFTNGP09.phx.gbl... > > > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in > > > message > > > > > news:e74T%238$8DHA.488@TK2MSFTNGP12.phx.gbl... > > > > > > Howard, > > > > > > > What do I need to do to trap the errors? > > > > > > Based on the "Fatal stack overflow error" printed, and the > following > > > > test. > > > > > > The VB.NET runtime for some reason is deciding to terminate your > > > > program, > > > > > as > > > > > > opposed to allowing you to catch the StackOverflowException that > is > > > > being > > > > > > thrown by the CLR: > > > > > > > > > > > > In the following (placed in your frmMessages) the > > > StackOverflowException > > > > > is > > > > > > caught & printed. > > > > > > > > > > > > Public Shared Sub TestRecursion() > > > > > > TestRecursion() > > > > > > End Sub > > > > > > > > > > > > Public Shared Sub Main() > > > > > > Try > > > > > > TestRecursion() > > > > > > Catch ex As Exception > > > > > > Debug.WriteLine(ex, "Main") > > > > > > End Try > > > > > > End Sub > > > > > > > > > > Yes, I can trap the error with separate code too. > > > > > > > > > > > It would appear that one or more of the runtime routines that you > > are > > > > > > calling have decided that we don't need to catch the > > > > > > StackOverflowException... > > > > > > > > > > I'm not calling any runtime routines. > > > > > > > > > > As I recall, I have eliminated all the On Error goTo -1, On Error > GoTo > > 0 > > > > and > > > > > Err.Clear statements, other than for the two Err.Clear in pDoQuick > and > > > the > > > > > .Clear in the two error processing subs. > > > > > > > > > > Each algorithm test starts with an On Error GoTo Somewhere, which > > should > > > > > clear previous errors. > > > > > > > > > > I just received a message from someone who was able to replicate the > > > > problem > > > > > and he included the files he used. > > > > > I've not yet had a chance to look at his files. > > > > > > > > > > > You do realize that the stack overflow is largely caused by a > "bug" > > in > > > > one > > > > > > of sort routines, that is not handling a sorted list correctly? If > > you > > > > > > change DataCreate to create a non-sorted array, the Stack overflow > > > does > > > > > not > > > > > > occur. Which to me suggests a bug in that specific routine... > > > > > > > > > > It's not a bug. > > > > > > > > > > One of the characteristics of quick sort is that, the fundamental > > > > algorithm > > > > > poorly handles presorted data and constant data. > > > > > There are ways to implement quicksort to reduce, but not eliminate > the > > > > > problem. > > > > > > > > > > For example, algorithms S7.1, S7.1- and S7.5 are also easily coerced > > > into > > > > a > > > > > stack space error (using a larger sample size, I forget the number), > > but > > > > > they have not yet exhibited the subsequent error behavior caused by > > > using > > > > > algorithm RS/pRS. > > > > > > > > > > Since the program is a test of various sorting algorihms, I cannot > > > recode > > > > > particular algorithms. One of the benefits of the program is going > to > > be > > > > to > > > > > inform folkes of the following. > > > > > > > > > > Just because an algorithm is published, in this case, in a quite > > useful > > > > > book, does not mean that the algorithm should be used without > further > > > > > investigation. > > > > > > > > > > Indeed, there is another algorithm, in an even more widely known > book, > > > > that > > > > > is even worse. > > > > > > > > > > > > Hope this helps > > > > > > Jay > > > > > > > > > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > > > > > news:ecW%237Tu8DHA.452@TK2MSFTNGP11.phx.gbl... > > > > > > > In a VB newsgroup, I've described an apparent problem with VB > 6. > > > > > > > > > > > > > > I've been able to replicate and demonstrate the problem. > > > > > > > > > > > > > > See the revised > > > > http://www.standards.com/temporary/OutOfStackSpace.html. > > > > > > > > > > > > > > I am now trying to determine whether the same behavior is seen > > with > > > VB > > > > > > .NET. > > > > > > > > > > > > > > There are no upgrade warnings when upgrading to VB .NET 2003, > > > however, > > > > I > > > > > > do
I don't agree that poorly designed code is a bug.
A compiler has to handle any legal program., be it good bad or ugly. -- http://www.standards.com/; See Howard Kaikow's web site. [quoted text, click to view] "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message news:uUAVmSJ9DHA.2856@TK2MSFTNGP10.phx.gbl... > Howard, > > I'm not calling any runtime routines. > > Yes! you are! I hope you realize that both Rnd, Int are VB.NET runtime > routines! > > > It's not a bug. > > Yes! It Is! I am not saying that it is a bug in your implementation of the > algorithm, per se. I am saying it is a bug in the algorithm itself. As you > stated in your other post. "The problem is caused by the less than robust > implementation of the quick sort algorithm, which is causing, according to > somebody else who has looked at this, at least 4 times as many levels of > recursion as some other algorithms" > > I'm consider a "less then robust implementation" to be a bug! > > What's that saying: a rose by any other name is still a rose... > > Hope this helps > Jay > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > news:%23YNQ6QH9DHA.2576@TK2MSFTNGP09.phx.gbl... > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > > news:e74T%238$8DHA.488@TK2MSFTNGP12.phx.gbl... > > > Howard, > > > > What do I need to do to trap the errors? > > > Based on the "Fatal stack overflow error" printed, and the following > test. > > > The VB.NET runtime for some reason is deciding to terminate your > program, > > as > > > opposed to allowing you to catch the StackOverflowException that is > being > > > thrown by the CLR: > > > > > > In the following (placed in your frmMessages) the StackOverflowException > > is > > > caught & printed. > > > > > > Public Shared Sub TestRecursion() > > > TestRecursion() > > > End Sub > > > > > > Public Shared Sub Main() > > > Try > > > TestRecursion() > > > Catch ex As Exception > > > Debug.WriteLine(ex, "Main") > > > End Try > > > End Sub > > > > Yes, I can trap the error with separate code too. > > > > > It would appear that one or more of the runtime routines that you are > > > calling have decided that we don't need to catch the > > > StackOverflowException... > > > > I'm not calling any runtime routines. > > > > As I recall, I have eliminated all the On Error goTo -1, On Error GoTo 0 > and > > Err.Clear statements, other than for the two Err.Clear in pDoQuick and the > > .Clear in the two error processing subs. > > > > Each algorithm test starts with an On Error GoTo Somewhere, which should > > clear previous errors. > > > > I just received a message from someone who was able to replicate the > problem > > and he included the files he used. > > I've not yet had a chance to look at his files. > > > > > You do realize that the stack overflow is largely caused by a "bug" in > one > > > of sort routines, that is not handling a sorted list correctly? If you > > > change DataCreate to create a non-sorted array, the Stack overflow does > > not > > > occur. Which to me suggests a bug in that specific routine... > > > > It's not a bug. > > > > One of the characteristics of quick sort is that, the fundamental > algorithm > > poorly handles presorted data and constant data. > > There are ways to implement quicksort to reduce, but not eliminate the > > problem. > > > > For example, algorithms S7.1, S7.1- and S7.5 are also easily coerced into > a > > stack space error (using a larger sample size, I forget the number), but > > they have not yet exhibited the subsequent error behavior caused by using > > algorithm RS/pRS. > > > > Since the program is a test of various sorting algorihms, I cannot recode > > particular algorithms. One of the benefits of the program is going to be > to > > inform folkes of the following. > > > > Just because an algorithm is published, in this case, in a quite useful > > book, does not mean that the algorithm should be used without further > > investigation. > > > > Indeed, there is another algorithm, in an even more widely known book, > that > > is even worse. > > > > > > Hope this helps > > > Jay > > > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > > news:ecW%237Tu8DHA.452@TK2MSFTNGP11.phx.gbl... > > > > In a VB newsgroup, I've described an apparent problem with VB 6. > > > > > > > > I've been able to replicate and demonstrate the problem. > > > > > > > > See the revised > http://www.standards.com/temporary/OutOfStackSpace.html. > > > > > > > > I am now trying to determine whether the same behavior is seen with VB > > > .NET. > > > > > > > > There are no upgrade warnings when upgrading to VB .NET 2003, however, > I > > > do > > > > have to change the Currency data type to Long for the purposes of the > > > > QueryPerformanceCounter API. I don't know why this is necessary, but > it > > is > > > > irrelevant to the issue I'm addressing. > > > > > > > > As you can see from my OutOfStackSpace.html document, a stack overflow > > > error > > > > should occur with a sample size of 6976. This is expected and the > > program > > > is > > > > designed to trap the error and continue. > > > > > > > > With VB .NET, the stack overflow occurs at a larger sample size of > 8908. > > > > However, when the error occurs, my error handlers are ignored. > > > > > > > > What do I need to do to trap the errors? > > > > > > > > -- > > > > http://www.standards.com/; See Howard Kaikow's web site. > > > > > > > > > > > > > > > > > > > >
Howard,
The only further help I will offer on this problem is: 1. Be mindful on unconstrained recursion. 2. Be mindful of anything that may be calling into microsoft.visualbasic.dll. Such as the CStr function. [quoted text, click to view] > .Text = CStr(CountMe) & ": " & x.ToString Based on your previous messages, #1 is not going to happen. #2 should be easy to identify as microsoft.visualbasic.dll is generally printed in the output window just before the "Fatal stack" message... You can also identify #2 by looking at the IL generated. Good Luck! Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:%23jLxhxL9DHA.2572@TK2MSFTNGP09.phx.gbl... > Using Rand does not cure the problem, just postpones the problem. > Same problem at a higher number of recursions. > > Private CountMe As Long = 0 > Private min As Long = 0 > Private max As Long = 999 > 'Private rand As New Random > Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles btnExit.Click > End > End Sub > Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles btnStart.Click > Try > TestRecursion() > Catch ex As Exception > Debug.WriteLine(ex, "btnStart") > End Try > End Sub > Private Sub TestRecursion() > Dim x As Double > ' Rnd or Int here... > x = Int((max - min + 1) * Rnd() + min) > 'x = rand.Next(min, max) > CountMe = CountMe + 1 > With lblRecursion > .Text = CStr(CountMe) & ": " & x.ToString > .Refresh() > End With > TestRecursion() > End Sub > >
The first is NOT a bug, it is by design
-- http://www.standards.com/; See Howard Kaikow's web site. [quoted text, click to view] "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:efzUZvL9DHA.1548@tk2msftngp13.phx.gbl... > Howard, > Unfortunately I believe you are missing the point I am attempting to make! > > There are *two* bugs going on here: > 1. The bug in your code that causes a stack overflow. > > 2. The bug in VB.NET that does not allow you to catch the above stack > overflow. > > You understandable are only concerned with the second. I am attempting to > point out both. > > Just a thought > Jay > > "Howard Kaikow" <kaikow@standards.com> wrote in message > news:OkXfpcL9DHA.2404@TK2MSFTNGP11.phx.gbl... > > I don't agree that poorly designed code is a bug. > > A compiler has to handle any legal program., be it good bad or ugly. > > > > -- > > http://www.standards.com/; See Howard Kaikow's web site. > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > > news:uUAVmSJ9DHA.2856@TK2MSFTNGP10.phx.gbl... > > > Howard, > > > > I'm not calling any runtime routines. > > > > > > Yes! you are! I hope you realize that both Rnd, Int are VB.NET runtime > > > routines! > > > > > > > It's not a bug. > > > > > > Yes! It Is! I am not saying that it is a bug in your implementation of > the > > > algorithm, per se. I am saying it is a bug in the algorithm itself. As > you > > > stated in your other post. "The problem is caused by the less than > robust > > > implementation of the quick sort algorithm, which is causing, according > to > > > somebody else who has looked at this, at least 4 times as many levels of > > > recursion as some other algorithms" > > > > > > I'm consider a "less then robust implementation" to be a bug! > > > > > > What's that saying: a rose by any other name is still a rose... > > > > > > Hope this helps > > > Jay > > > > > > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > > news:%23YNQ6QH9DHA.2576@TK2MSFTNGP09.phx.gbl... > > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in > > message > > > > news:e74T%238$8DHA.488@TK2MSFTNGP12.phx.gbl... > > > > > Howard, > > > > > > What do I need to do to trap the errors? > > > > > Based on the "Fatal stack overflow error" printed, and the following > > > test. > > > > > The VB.NET runtime for some reason is deciding to terminate your > > > program, > > > > as > > > > > opposed to allowing you to catch the StackOverflowException that is > > > being > > > > > thrown by the CLR: > > > > > > > > > > In the following (placed in your frmMessages) the > > StackOverflowException > > > > is > > > > > caught & printed. > > > > > > > > > > Public Shared Sub TestRecursion() > > > > > TestRecursion() > > > > > End Sub > > > > > > > > > > Public Shared Sub Main() > > > > > Try > > > > > TestRecursion() > > > > > Catch ex As Exception > > > > > Debug.WriteLine(ex, "Main") > > > > > End Try > > > > > End Sub > > > > > > > > Yes, I can trap the error with separate code too. > > > > > > > > > It would appear that one or more of the runtime routines that you > are > > > > > calling have decided that we don't need to catch the > > > > > StackOverflowException... > > > > > > > > I'm not calling any runtime routines. > > > > > > > > As I recall, I have eliminated all the On Error goTo -1, On Error GoTo > 0 > > > and > > > > Err.Clear statements, other than for the two Err.Clear in pDoQuick and > > the > > > > .Clear in the two error processing subs. > > > > > > > > Each algorithm test starts with an On Error GoTo Somewhere, which > should > > > > clear previous errors. > > > > > > > > I just received a message from someone who was able to replicate the > > > problem > > > > and he included the files he used. > > > > I've not yet had a chance to look at his files. > > > > > > > > > You do realize that the stack overflow is largely caused by a "bug" > in > > > one > > > > > of sort routines, that is not handling a sorted list correctly? If > you > > > > > change DataCreate to create a non-sorted array, the Stack overflow > > does > > > > not > > > > > occur. Which to me suggests a bug in that specific routine... > > > > > > > > It's not a bug. > > > > > > > > One of the characteristics of quick sort is that, the fundamental > > > algorithm > > > > poorly handles presorted data and constant data. > > > > There are ways to implement quicksort to reduce, but not eliminate the > > > > problem. > > > > > > > > For example, algorithms S7.1, S7.1- and S7.5 are also easily coerced > > into > > > a > > > > stack space error (using a larger sample size, I forget the number), > but > > > > they have not yet exhibited the subsequent error behavior caused by > > using > > > > algorithm RS/pRS. > > > > > > > > Since the program is a test of various sorting algorihms, I cannot > > recode > > > > particular algorithms. One of the benefits of the program is going to > be > > > to > > > > inform folkes of the following. > > > > > > > > Just because an algorithm is published, in this case, in a quite > useful > > > > book, does not mean that the algorithm should be used without further > > > > investigation. > > > > > > > > Indeed, there is another algorithm, in an even more widely known book, > > > that > > > > is even worse. > > > > > > > > > > Hope this helps > > > > > Jay > > > > > > > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > > > > news:ecW%237Tu8DHA.452@TK2MSFTNGP11.phx.gbl... > > > > > > In a VB newsgroup, I've described an apparent problem with VB 6. > > > > > > > > > > > > I've been able to replicate and demonstrate the problem. > > > > > > > > > > > > See the revised > > > http://www.standards.com/temporary/OutOfStackSpace.html. > > > > > > > > > > > > I am now trying to determine whether the same behavior is seen > with > > VB > > > > > .NET. > > > > > > > > > > > > There are no upgrade warnings when upgrading to VB .NET 2003, > > however, > > > I > > > > > do > > > > > > have to change the Currency data type to Long for the purposes of > > the > > > > > > QueryPerformanceCounter API. I don't know why this is necessary, > but > > > it > > > > is > > > > > > irrelevant to the issue I'm addressing. > > > > > > > > > > > > As you can see from my OutOfStackSpace.html document, a stack > > overflow > > > > > error > > > > > > should occur with a sample size of 6976. This is expected and the > > > > program > > > > > is > > > > > > designed to trap the error and continue. > > > > > > > > > > > > With VB .NET, the stack overflow occurs at a larger sample size of > > > 8908. > > > > > > However, when the error occurs, my error handlers are ignored. > > > > > >
Using Rand does not cure the problem, just postpones the problem.
Same problem at a higher number of recursions. Private CountMe As Long = 0 Private min As Long = 0 Private max As Long = 999 'Private rand As New Random Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExit.Click End End Sub Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnStart.Click Try TestRecursion() Catch ex As Exception Debug.WriteLine(ex, "btnStart") End Try End Sub Private Sub TestRecursion() Dim x As Double ' Rnd or Int here... x = Int((max - min + 1) * Rnd() + min) 'x = rand.Next(min, max) CountMe = CountMe + 1 With lblRecursion ..Text = CStr(CountMe) & ": " & x.ToString ..Refresh() End With TestRecursion() End Sub
Howard,
Cool! You've demostarted that I was wrong! The Microsoft.VisualBasic assembly is not killing your program! Hence there will be no need to avoid the functions in that assembly!!! I was a little concerned that Microsoft had code in the Microsoft.VisualBasic assembly that purposely used End to abruptly terminate the program... I'm really not sure what else to offer... Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:ugWdb5M9DHA.3348@TK2MSFTNGP09.phx.gbl... > In order to eliminate the effects of upgrading from VB 6 to VB .NET 2003, I > created a fresh VB .NET 2003 project and put the following code in a form. > The form has a label lblRecursion, a button btnStart and a button btnExit. > > The stack overflow is not trapped by the Try/Catch. Using Rnd, instead of > Random, just causes the stack overflow to occur sooner. > > The equivalent VB 6 code does trap the stack overflow in the error handler. > '--------------------------------------------------------------------------- > ----- > > Private CountMe As Integer > Private Const min As Integer = 0 > Private Const max As Integer = 999 > Private randy As New Random > > Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles btnStart.Click > CountMe = 0 > Try > TestRecursion() > Catch > MsgBox(Err.Number & ": " & Err.Description, , "HK") > lblRecursion.Refresh() > End Try > End Sub > > Private Sub TestRecursion() > Dim x As Double > 'x = Int((max - min + 1) * Rnd() + min) > x = randy.Next(min, max) > CountMe = CountMe + 1 > With lblRecursion > .Text = CountMe.ToString & ": " & x.ToString > .Refresh() > End With > TestRecursion() > End Sub > > Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles btnExit.Click > End > End Sub > >
Howard,
This KB is not an exact match, but it sounds suspiciously close: http://support.microsoft.com/default.aspx?scid=kb;en-us;326611 Hope this helps Jay [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:ugWdb5M9DHA.3348@TK2MSFTNGP09.phx.gbl... > In order to eliminate the effects of upgrading from VB 6 to VB .NET 2003, I > created a fresh VB .NET 2003 project and put the following code in a form. > The form has a label lblRecursion, a button btnStart and a button btnExit. > > The stack overflow is not trapped by the Try/Catch. Using Rnd, instead of > Random, just causes the stack overflow to occur sooner. > > The equivalent VB 6 code does trap the stack overflow in the error handler. > '--------------------------------------------------------------------------- > ----- > > Private CountMe As Integer > Private Const min As Integer = 0 > Private Const max As Integer = 999 > Private randy As New Random > > Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles btnStart.Click > CountMe = 0 > Try > TestRecursion() > Catch > MsgBox(Err.Number & ": " & Err.Description, , "HK") > lblRecursion.Refresh() > End Try > End Sub > > Private Sub TestRecursion() > Dim x As Double > 'x = Int((max - min + 1) * Rnd() + min) > x = randy.Next(min, max) > CountMe = CountMe + 1 > With lblRecursion > .Text = CountMe.ToString & ": " & x.ToString > .Refresh() > End With > TestRecursion() > End Sub > > Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles btnExit.Click > End > End Sub > >
In order to eliminate the effects of upgrading from VB 6 to VB .NET 2003, I
created a fresh VB .NET 2003 project and put the following code in a form. The form has a label lblRecursion, a button btnStart and a button btnExit. The stack overflow is not trapped by the Try/Catch. Using Rnd, instead of Random, just causes the stack overflow to occur sooner. The equivalent VB 6 code does trap the stack overflow in the error handler. '--------------------------------------------------------------------------- ----- Private CountMe As Integer Private Const min As Integer = 0 Private Const max As Integer = 999 Private randy As New Random Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnStart.Click CountMe = 0 Try TestRecursion() Catch MsgBox(Err.Number & ": " & Err.Description, , "HK") lblRecursion.Refresh() End Try End Sub Private Sub TestRecursion() Dim x As Double 'x = Int((max - min + 1) * Rnd() + min) x = randy.Next(min, max) CountMe = CountMe + 1 With lblRecursion .Text = CountMe.ToString & ": " & x.ToString .Refresh() End With TestRecursion() End Sub Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExit.Click End End Sub
Looks like it's in the same ballpark.
How do I avoid using "precompiled assemblies"? Does that mean using only a p-code .exe? How do I know whether I'm using ngen.exe? -- http://www.standards.com/; See Howard Kaikow's web site. [quoted text, click to view] "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message news:O6Vn8WN9DHA.2316@TK2MSFTNGP09.phx.gbl... > Howard, > This KB is not an exact match, but it sounds suspiciously close: > > http://support.microsoft.com/default.aspx?scid=kb;en-us;326611 > > Hope this helps > Jay > > "Howard Kaikow" <kaikow@standards.com> wrote in message > news:ugWdb5M9DHA.3348@TK2MSFTNGP09.phx.gbl... > > In order to eliminate the effects of upgrading from VB 6 to VB .NET 2003, > I > > created a fresh VB .NET 2003 project and put the following code in a > form. > > The form has a label lblRecursion, a button btnStart and a button btnExit. > > > > The stack overflow is not trapped by the Try/Catch. Using Rnd, instead of > > Random, just causes the stack overflow to occur sooner. > > > > The equivalent VB 6 code does trap the stack overflow in the error > handler. > > > '--------------------------------------------------------------------------- > > ----- > > > > Private CountMe As Integer > > Private Const min As Integer = 0 > > Private Const max As Integer = 999 > > Private randy As New Random > > > > Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As > > System.EventArgs) Handles btnStart.Click > > CountMe = 0 > > Try > > TestRecursion() > > Catch > > MsgBox(Err.Number & ": " & Err.Description, , "HK") > > lblRecursion.Refresh() > > End Try > > End Sub > > > > Private Sub TestRecursion() > > Dim x As Double > > 'x = Int((max - min + 1) * Rnd() + min) > > x = randy.Next(min, max) > > CountMe = CountMe + 1 > > With lblRecursion > > .Text = CountMe.ToString & ": " & x.ToString > > .Refresh() > > End With > > TestRecursion() > > End Sub > > > > Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As > > System.EventArgs) Handles btnExit.Click > > End > > End Sub > > > > > >
Of course, the stack overflow, in my case, would be correct, not erroneous
behavior. The only issue is how to trap the critter. -- http://www.standards.com/; See Howard Kaikow's web site. [quoted text, click to view] "Howard Kaikow" <kaikow@standards.com> wrote in message news:OqJgKxO9DHA.2832@tk2msftngp13.phx.gbl... > Looks like it's in the same ballpark. > > How do I avoid using "precompiled assemblies"? > Does that mean using only a p-code .exe? > > How do I know whether I'm using ngen.exe? > > -- > http://www.standards.com/; See Howard Kaikow's web site. > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message > news:O6Vn8WN9DHA.2316@TK2MSFTNGP09.phx.gbl... > > Howard, > > This KB is not an exact match, but it sounds suspiciously close: > > > > http://support.microsoft.com/default.aspx?scid=kb;en-us;326611 > > > > Hope this helps > > Jay > > > > "Howard Kaikow" <kaikow@standards.com> wrote in message > > news:ugWdb5M9DHA.3348@TK2MSFTNGP09.phx.gbl... > > > In order to eliminate the effects of upgrading from VB 6 to VB .NET > 2003, > > I > > > created a fresh VB .NET 2003 project and put the following code in a > > form. > > > The form has a label lblRecursion, a button btnStart and a button > btnExit. > > > > > > The stack overflow is not trapped by the Try/Catch. Using Rnd, instead > of > > > Random, just causes the stack overflow to occur sooner. > > > > > > The equivalent VB 6 code does trap the stack overflow in the error > > handler. > > > > > > '--------------------------------------------------------------------------- > > > ----- > > > > > > Private CountMe As Integer > > > Private Const min As Integer = 0 > > > Private Const max As Integer = 999 > > > Private randy As New Random > > > > > > Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As > > > System.EventArgs) Handles btnStart.Click > > > CountMe = 0 > > > Try > > > TestRecursion() > > > Catch > > > MsgBox(Err.Number & ": " & Err.Description, , "HK") > > > lblRecursion.Refresh() > > > End Try > > > End Sub > > > > > > Private Sub TestRecursion() > > > Dim x As Double > > > 'x = Int((max - min + 1) * Rnd() + min) > > > x = randy.Next(min, max) > > > CountMe = CountMe + 1 > > > With lblRecursion > > > .Text = CountMe.ToString & ": " & x.ToString > > > .Refresh() > > > End With > > > TestRecursion() > > > End Sub > > > > > > Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As > > > System.EventArgs) Handles btnExit.Click > > > End > > > End Sub > > > > > > > > > > > >
Howard, [quoted text, click to view] > Does that mean using only a p-code .exe? VB.NET does not support a p-code .exe![quoted text, click to view] > How do I avoid using "precompiled assemblies"? The only way to avoid using "precompiled assemblies" is to totally avoid theF |