Illegal Operation Blues

[Brent Boshart]

I am working on a program (with PBDLL 6.0)that keeps giving me "illegal operation" errors.

After many hours I still can not isolate the problem. My arrays are properly dimensioned, all paramter passing seems to be okay. I am using DDT and Powertree.

Any ideas where I should continue to hunt for the problem? (Very frustrated.)

[Eric Pearson]

Brent --

In essence, your message is roughly the same as "My car keeps stalling. I'm not out of gas and the air filter is clean. What else could it be?" {G} I'm not trying to give you a hard time, we'll just need a LOT more information before anybody can help you. It could be hundreds of different things.

Have you isolated the GPF to a single module, single function, or a single line of code? Can you "boil down" the program, removing code until the problem goes away? Is the problem reliable, i.e. can you always make it happen by doing a certain thing, or is it random? Are you using pure PB code or are you using API functions? Are you using arrays in your UDTs? Does the Application Error message say that the error is taking place in your program, or in the PowerTree DLL, or...? Does it seem related to DDT (your GUI) or PowerTree? Can you provide a small test program that fails? Does the problem go away when you use #DEBUG ERROR ON and/or #REGISTER NONE? What part of the program were you working on when the problem appeared? Have you tried stepping through the program with the debugger?

There are lots of people here who will be glad to help, if you can give us a few more clues...

-- Eric


-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited January 04, 2000).]

[Brent Boshart]

Thanks Eric.

I understand your comments. Thats my problem, I have not been able to isolate the problem to a certain area of code. There just seems to be no rhyme or reason.

Using #DEBUG ERROR ON and/or #REGISTER NONE doesnt make the problem disappear. The error occurs when running my code however, in one place it occurs when calling a Powertree function (in which I am sure the parameters are correct - I've used PowerTree extensively in other apps)

I am using DDT exclusively and at this point don't make calls directly to win32 api. However, I do a lot of deleting and creating controls. My best guess is a problem in parameter passing somewhere.

[Scott Turchin]

Let me toss in a minor suggestion, this helps me a LOT when debugging code:


Msgbox "Test 1", %MB_ICONSTOP,"TESTING"
CODE

Msgbox "Test 2", %MB_ICONSTOP,"TESTING"


Anyway, when the GPF occurs you'll have a count of wh ere it's at, works for me

Scott



-------------
Scott Turchin

[Eric Pearson]

Brent --

> I do a lot of deleting and creating controls.

You might try disabling the controls with CONTROL DISABLE instead of using CONTROL KILL, to see if that affects the problem. I have experienced problems with deleted controls in the past (using API function, not DDT). If that is too messy, you might try using the ShowWindow API to hide controls rather than deleting them. Just to see if the problem goes away.

> I have not been able to isolate the problem to
> a certain area of code.

Are you saying that the problem moves around? That when you try to isolate the location it seems to move from place to place? After a crash, if you run the exact same program a second time, does it fail in exactly the same way or does it change? When you add things like MSGBOXs, BEEPs, and PRINT#-to-file lines to try to nail down the location, are you saying that it doesn't work for some reason? What about the debugger?

It's a lot of work, but an extremely effective technique is to OPEN a "trace file" at the very beginning of your program, and then have various subs and functions use PRINT # to append strings like "starting MyFunc" to the file, as the program runs. The last item in the file (after a crash) will give you a clue as to where to add more PRINT # lines, until you find the exact line of code that is causing the problem.

When I add code like that to a program I don't actually remove it... I just use things like this:

$IF %Testing
    PRINT #99, "OK TO HERE"
$ENDIF

...to tell the compiler not to compile those sections unless I set %Testing=%True. That way I can re-activate the test code later, if I experience more problems.

In my most sophisticated programs I use a function I call ProgramCounter. All through the program you see lines like this...

ProgramCounter 72656

The ProgramCounter function can do many different things, depending on the value of a "mode" variable. Most of the time the mode is zero and the function simply exits. If the mode setting tells it to, ProgramCounter can display the numbers (sequentially) in the program's status bar, or write the values to a disk file, etc. etc.

HTH.

-- Eric


-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Brent Boshart]

Thanks for your ideas Eric.

I have been putting in "markers" with msgbox (eg. msgbox "Made it this far.") But it hasn't helped to isolate the problem, as it happens in various places where I am sure the code is okay. It would seem that the "bad code" doesn't generate the error immediately but later the time bomb goes off with "innocent" code. Its very bizarre. I guess I just need to go through everything line by line to look for bad parameters or something.

My use of the CONTROL KILL function is very unorthodox. My entire problem uses one dialog in which I continually kill and create controls uses DDT. (sort of like DOS programming and the CLS function again!) Makes for an interesting interface!

[Semen Matusovski]

Brent --
Could be will be useful MemCheck 5.0 http://www.stratosware.com/products/...cw50/gimme.htm
(evaluation period - 14 days)
It's a little stupid tool - cries sometimes, even if not necessary.

[Brent Boshart]

It seems like this may be a problem related to calling PowerTree functions which means I cannot discuss it further on the forums as code for PowerTree cannot be posted. Thanks for your help.