New reproducible crash on 8.5-final server and client

Shortly after upgrading a server at my company to the final release of Domino 8.5, we started experiencing crashes. After some troubleshooting, I narrowed down the problem to a specific agent called by HTTP URL that had been working fine in all previous versions of the server (various versions of 7.0.x and 8.0.x); after further investigation, I found that the problem was reproducible on several machines in clean databases and occurred during traversal of a view using a NotesViewNavigator. I narrowed down a reproducible crash when running an agent containing only this code:

==================================================================

Dim session As New NotesSession, db As NotesDatabase

Set db = session.CurrentDatabase

Dim deathView As NotesView

Set deathView = db.GetView(“DeathView”)

Dim nav As NotesViewNavigator, entry As NotesViewEntry

Set nav = deathView.CreateViewNav

Set entry = nav.GetFirst

Do While Not (entry Is Nothing)

Set entry = nav.GetNext(entry)

Loop

Subject: Forwarded to development <>

Programmability/LotusScript backend classes/pr/jc

Subject: We are also receiving this issue within our Lotus Notes application

We are also receiving this in a very specific area of our application. We perform http request to run an agent that returns a stream of XML to a browser with search results based on previously defined criteria.

This routine has worked for years (originally designed for Domino 6.5.2) Now with V8.5 GA it causes the server to completely halt with an eventual crash.

We are now redesigning our routine to access the documents recursively instead of using a View Navigator. What used to take less than 5 seconds to run is now taking over 2 minutes.

Is there a time frame for a solution to this issue?

Subject: I ran into the post length limit

My original post was much lengthier than the one visible now, so I uploaded the text of it here:

http://frostillic.us/stuff/domino-crash.txt

Subject: I reproduced the problem and entered it as an SPR

SPR# PRUN7NFPLXI also attached the database I used to reproduce the problem (from your info, thank you) as well as the nsd that resulted. (It reproduces when run from the client as well as from HTTP, by the way.)