Hi All

I'm sure I've dealt with this before but the fixes I tried for this time haven't worked.

I have a client who moved their OI app installed on a standalone NT workstation to the NT network (server). They do not have the linear hash service (NT NLM thingy) installed. We are talking single user on a reasonably reliable network so you think it would be happy but no.

I am trying to figure out why a particular report GPFs when I run it. It has OIPI in it but doesn't usually get that far. I copied the whole system to our Novell Network, and proceeded to fiddle in an attempt to get it to work properly.

First, they seemed to be using the dev oengine.exe instead of the runtime version, but I need to debug the report so I have left that.

I put debug in the report and recompiled it.

GPF's in Revdebug.dll

I changed the netdrv thingy from all networks 1.5.0.0 to netware 1.14 (ours not the clients)

Still GPF's (and I reboot again)

I copied the all the OI dlls from our working copy to the Client copy (on our network)

Still GPF's

I could attempt putting it on our NT server, we have NT server as well as Novell, our lan however, uses novell. The NT server is a bit tight for space too.

I'm running out of ideas, I don't know what I am going to have to do to fix the report and test it if it won't debug.

Anyone else have any ideas on this. If the client is a single user with the app on the NT network do they need the NT "NLM" ?

Scott

It never rains but it pours.

Scott,

Have you searched the site for postings on GPF in REVDEBUG.DLL? E.g try GPF and "REVDEBUG.DLL".

Which version of OI are you on? If you do that search one of the documents you'll find says the 3.7.2 Upgrade fixed a couple of COMMON-related bugs causing GPF in REVDEBUG.DLL.

And you'll find one of your own postings too. Perhaps it's the same problem as last time.

- Oystein -

Scott

I think you have two problems. Firstly, a GPF is caused whenever the debugger is called. Secondly, you have a specific report which is consistently generating an error, which attempts to summon the debugger and generates the GPF. In all likelihood, it will be a dictionary item in the report which is not available and therefore trying to generate the "Sys 1002 Dictionary item is not available" message. Try reducing the report down to bare minimum or recheck the dictionary items.

As for why the debugger crashes? Have you upgraded to 3.7.? on both your development system AND your runtime system or have they got out of sync?

Hi All

Yes I did the search on the revdebug stuff, it was odd that searches on "revdebug.dll" didn't consistently return the same stuff, but I did try some of the fixes suggested and they didn't work.

I have found a bug in the report where a variable is not assigned. the user had managed to find one of those ways of running the system that we hadn't thought of. They are also running on an older version on the app and we had fixed the problem in the new version but they won't pay for that. Grrr. Now I have to maintain two versions of my app.

We seem to have version 3.7 of oengine across the board, for dev anyway. I am worried about upgrading because the application depends on being able to do copy table in the runtime version.

I think now I have time to try it out, if I can find the upgrade cd we had. Hmm, I've never done an upgrade. There are just so many things that could quietly break that I wouldn't notice for months and then backing out would be very difficult.

I debugged the report by attaching the data to my development copy and running that. And yes there was an unrelated missing dictionary item, which crashed the data enquiry window, as opposed to the report.

So I have a few updates to make.

Scott

Scott,

odd that searches on "revdebug.dll" didn't consistently return the same stuff

There are several places you can do a search. One is the Site Search tool in the vertical side bar. Site Search searches all (?) the lists, including technical articles and stuff. Then there's the Search this list tool for each list - one for the common list, one for the Works list, etc.

Site Search indeed works differently from the others. Is that what you mean?

Site Search generally performs better, but unfortunately presents the result list without subject, except for the older postings.

- Oystein -

But let's float the standard REVDEBUG reason…. any labeled common Scott?

The Sprezzatura Group

World Leaders in all things RevSoft

If you have more than 10 (maybe 11, can't remember) labelled commons in the system, you'll get GPFs in the debugger. Usually you can scroll your way through an ignore them. Just don't try and look at any of the labeled common vars though.

Known bug, reported years ago.

The Sprezzatura Group

World Leaders in all things RevSoft

Guys-

This bug was fixed in release 3.7.2

Mike Ruane

Dude

Several debug fixes round about 3.7.2

OpenEngine

· Fixed a bug that caused OpenEngine to incorrectly report that the licensed user count had been exceeded when using both development and runtime systems with the same 8-digit serial number suffix. (SYSOBJ/$LOAD_SYSPROGDBT, REVBOOT)

· Fixed a bug that caused OpenEngine to GPF if it had to GARBAGECOLLECT while bringing up the debugger. (OENGINE.EXE)

· Fixed a bug that caused the debugger to GPF when stepping over a FREECOMMON statement. (SPR#CPUY3N4LWH) (REVDEBUG.DLL)

· Fixed a bug that caused the debugger to GPF when stepping through a BASIC+ program that used more than 11 labelled common blocks. (SPR#CPUY3N4LV9) (REVDEBUG.DLL)

The Sprezzatura Group

World Leaders in all things RevSoft

Correct.

The 3.7.1 readme and 3.7.2 readme seem to match, as 3.7.2 could be applied to 3.7 or 3.7.1

Regardless, the bug is fixed.

Mike

Scott is still using 3.7 and has expressed a reluctance to upgrade, so the bug is still valid for this version, is it not?

The Sprezzatura Group

World Leaders in all things RevSoft

]· Fixed a bug that caused OpenEngine to GPF if it had to ]GARBAGECOLLECT while bringing up the debugger. (OENGINE.EXE)

Under what circumstances is the debugger required to "garbage collect". This could explain a few of our problems as our sites would not be up to 3.7.2.

]· Fixed a bug that caused the debugger to GPF when stepping through ?]a BASIC+ program that used more than 11 labelled common blocks.

](SPR#CPUY3N4LV9) (REVDEBUG.DLL)

We have three "labeled common groups" with a total of about 30 variables. To clarify the fix in 3.7.2, this wouldn't affect us as the issues is common groups not common variables? Correct?

Hi All

I have made the debug problem go away by fixing an unassigned variable (did I say that already?).

I have 1 labelled common in this particular program, we don't use it much. There might be 4 in another program that may be running at the same time - I don't think it would be running but I don't know everything about this app.

I don't call garbagecollect in this program. We don't use that much either.

I don't have any free common statements.

I don't think I have any problem with user licences. (How do you tell?)

Yes I did use two different search engines. Got a lot more info out of the site search, but it was harder to identify the useful stuff.

I would take a punt and say that if a few bugs associated with the debugger (irony) have been ironed out, that maybe this one would be too. I guess I will have to save that until I get to experiment with the upgrades. I have the bug on CD. Nicely preserved like a pinned cockroach.

I have a strong feeling it had more to do with the client database coming from an NT platform and me trying to figure it out on a Novell platform. Because I found where the problem was by attaching the client's data to my development (Novell) version of the system. The program does use OIPI, which has a different install procedure for NT. I don't know if that had anything to do with the price of eggs in a siberian fish market.

Scott

Robert ..

The debugger may have to do a GARBAGECOLLECT to allocate work space for its own variables. If string space has become too fragmented for it to load one or more arrays, it will force a GARBAGECOLLECT during initialization and before it loads. I've only seen this when we've been doing heavy-duty development efforts.

The labelled common issue has to do with more than 10 declarations and not how many variables are contained therein.

HTH

Don Miller

C3 Inc.

View this thread on the forum...