Problem With New Compiler

[Jim Seekamp]

I'm having trouble with some compression code I've used for a long time (7-8 years) with no problems til now.

9.01 compiles the code fine
9.02 compiles the code with no errors
BUT the result in 9.02 -- with the exact same code-- is jarbled.

Did something change as far as variables or limitations in 9.02 ???

[Bob Zale]

Do you think you could provide a definition of jarbling?

That might help a good deal.

Bob Zale
PowerBASIC Inc.

[Jim Seekamp]

OK - sorry Bob...
What I mean is that the data the compression code restores to now turns out incorrect -- it looks "jarbled" when restored. The backup and restore have both worked for 7-8 years and we have hundreds of customers successfully using it.
But with 9.02 it does not work the same.
Just curious as to any changes in the compiler.
For now I went back to the 9.01 compiler
Jim

[Bob Zale]

There is no way of knowing by mystical/magical means. {smile} However, given performance history, it is very unlikely that it has anything to do with the compiler. Possible, but unlikely. If you stay with 9.01, it's likely that a similar situation will arise at some point, when you change your code to cause a different form of (unwanted) corruption.

I would highly recommend that you use 9.02 to debug and locate the real source of the problem. PowerBASIC Tech Support will help, as always, just ask.

Bob Zale
PowerBASIC Inc.

[Brian Chirgwin]

Example?

I'm having trouble with some compression code I've used for a long time (7-8 years) with no problems til now.

9.01 compiles the code fine
9.02 compiles the code with no errors
BUT the result in 9.02 -- with the exact same code-- is jarbled.

Did something change as far as variables or limitations in 9.02 ???

One this to try is #Register None at the top of the application.

Can you upload a simplified example? When I have a corruption like this I usually make a copy of the source and cut out as much as a can In most cases, I find I made a stupid, hard to find error. Sometimes I can't find it and post the simplified problem.

If the PB 9.02 application writes out data, can the 9.02 read it? How about the PB 9.01 version. This may help indicate if the problem is in the read or write portion of the code.

[Jim Seekamp]

Unfortunately, the application is huge, and has 5 exe modules, and this is in the main module that is over 1mb compiled...

I tried compressing in the one compiled by 9.01 and decompressing with the one compiled in 9.02, and that worked, so it's in the compression. The code has no apparent errors and is not that complex. The register none statement has been in the code for a long time. But thanks for the suggestions

[Bernhard Fomm]

The error of ISFILE9.02 is a known bug.
It has changed the functionality and are errors on Windows 7!

[Bob Zale]

Any time there's an updated version of a compiler, code and data in your program will move to a new location. This is generally true, even with the most minor compiler changes. If your code is perfect, it won't be affected at all. But, if there are any problems, the resulting errors may be magnified.

For example, if you have an array bounds error, or a pointer error, you may be reading and writing data to the wrong memory location. Using one version of the compiler, that wrong location may (by pure chance) turn out to be a string which is only used once when your program starts. In this particular case, no harm is done, so the program appears to work flawlessly. However, move to a new compiler version, things shift around a little, and you could face a major problem. All of a sudden, your code may now be incorrectly altering a variable which is critical to your program and everything comes crashing down. Usually at the worst possible moment.

Of course, it's easy to blame the compiler. I've made that mistake myself with TASM, the assembler I use to create PowerBASIC. But that may give you a false and fleeting sense of security. If that happens, I guarantee that it will come back to bite you at the most critical time.

Six months from now, you may make a small change to this code. Even if it's in a totally unrelated part of the code, it will also cause a shift in the internal memory map of the program. What happens then? That supposedly harmless bounds error may once again cause great havoc for you. And the side effects may be even more treacherous.

My recommendation would be to use this "problem" as a helpful warning signal. Extract the portion of code which is causing a problem. Surely the compression code alone is not a megabyte? Put it in a smaller standalone program and compare numerous intermediate results when compiled with the two versions. Use the debugger for that, or insert a bunch of Message Boxes to display progress at various stages of execution until you find the real underlying difference. You may just find that you're preventing a truly major problem in the future. And at worst, you might locate a compiler issue, but that, too, is something which we can correct. The best case is that you'll help yourself by avoiding a future problem; the worst case is that you'll help your many friends here by uncovering a problem which is "fixable". As always, you can depend upon PowerBASIC support ([email protected]) to assist as much as they can.

One other thing to try first? Compile with #DEBUG ERROR and #DEBUG DISPLAY enabled. Then run it again and see what you might discover.

Best of luck...

Bob Zale
PowerBASIC Inc.

[Jim Seekamp]

Thanks Bob - I'm in the process of attempting to debug, which is difficult with no errors, since every step has to be monitored! LOL

[Brian Chirgwin]

Unfortunately, the application is huge, and has 5 exe modules, and this is in the main module that is over 1mb compiled...

I tried compressing in the one compiled by 9.01 and decompressing with the one compiled in 9.02, and that worked, so it's in the compression. The code has no apparent errors and is not that complex. The register none statement has been in the code for a long time. But thanks for the suggestions

I am sure you can pull the decompression/compression pieces out to a small application. In fact, you might have Decomp.inc and Compress.inc, or maybe it is one file, that is included in your application. Create a new program that includes the one or two files. This could just have a simple UI or no UI that compresses and decompresses the file and compares the results. Doesn't even have to be a file. Compress a large string.

If this works, the problem could be something else in your code. I have seen the problem you have. In my case I think it was an array bounds error. I was going 1 index past the max and writing data. This worked in one version of the compiler, but the next version it caused an error. I assume I was overwritting code or other data. Maybe in the working version of the compiler a No op was overwritten, no harm done.

I use this technique of writing simple samples quite often. I keep them and it saves a lot of time.

I very much doubt it is the compiler, but without seeing code I can think of only one other possibility. Are the two compilers set to use the same paths for Win.api and other include paths? Are they listed in the exact same order. If not, you could be compiling set of include files where the 9.02 is using "buggy" versions.

[Michael Mattias]

I'm in the process of attempting to debug, which is difficult with no errors, since every step has to be monitored! LOL

TRACE!!!!
Great Tool for this kind of thing!!!!

[Jim Seekamp]

I removed the simplified version of the code I pulled out of the program to test on its own, and it does not work in PB 9.02 either. It does work in PB 9.01. Simple backtracking compression. I haven't found any problems yet, but still going through it. Sent it to PB support.

[Stanley Durham]

worked for me 9.02
no errors

be sure to try
>> Brian Chirgwin >> #Register None

[Jim Seekamp]

Try a large text file with a bunch of smaller ones. It doesn't work.

[Tom Hanlin]

I think that's "garbled"...?

Anyway, I can't duplicate the problem here. Works fine with large text files.

[Jim Seekamp]

11

[Jim Seekamp]

Here are the files I am testing; I zipped them up.
unzip them and then try compressing and decompressing them with the code above. The file with extension P1 is a text file that can be read with notepad. It is definitely different after decompression than before being compressed.

http://www.eekinfo.com/testfiles.zip

[Steve Rossell]

I tested this with a 528KB text file and the results were identical (at least according to WinDiff when comparing the cmp files). I also stepped through both of them in the debugger and watched all the variables and they contained the same values. May be you can give exact steps to replicate this and explain how to see any incorrect results in 9.02? Have you tried stepping through both 9.01 and 9.02 at the same time and comparing the data? Send this information to [email protected] and they will be happy to try to replicate it.

[Jim Seekamp]

Steve - try the files I posted in the previous post

[Cliff Nichols]

Nevermind, I see you posted while I was typing.......disregard this post