Announcement

Collapse
No announcement yet.

Problem With New Compiler

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Paul Purvis
    replied
    Jim
    for what it is worth. Install pb p.02 cleanly on a separate computer and run your compile with all files on a local drive then compare executables.
    There should only be a few differences.
    Maybe only 16 of them. I wish every time i compiled the same source code with the same compiler, the executables would match exactly.
    But go ahead compare both results from separate machines.
    Also compile twice with the same machine and compare the executable results.
    Maybe pb support will compile it also and send you the executable results.
    May want to create the md5 results with md5sum to make sure source code is exact.
    Good luck. It took me two years to track down one of my problems in the past.

    Leave a comment:


  • Bob Zale
    replied
    Hi Gil--

    The real problem here is that we have absolutely no way to know if you are experiencing a compiler issue here. That's because you have not given us an example of failing code. None whatever, just a vague description of "INSTR is a problem".

    Now, we are fairly sure there can sometimes be a mismatch problem when the mask contains trailing nuls, and we're currently testing that exhaustively. However, even when testing is complete, we can only hope... and guess that your problem is part of that issue, as we're unable to check out what you may be seeing.

    I understand it may be difficult to provide an example, so we'll just go forward and hope it is corrected as expected. But please understand we cannot guarantee what we cannot see.

    Best regards,
    Bob

    Leave a comment:


  • Ben Zvi Gil
    replied
    PB 9.02 problem

    Hi Jim –

    Do you have any news regarding the problems you described?

    I am having a lot of problems too (with PB 9.02). Two major applications of mine that have been recompiled in the past years with each PB update (since PBDll5) and always worked as expected are totally broken now. They will exit with a GPF at some point which is not fixed even for the same set of input files. I have found (after a very long checking process) that the problem is related to the "improved" Instr function in PB 9.

    I have reported this problem to PB support 5 days ago including a description of a generic workaround I have found (which is not to use Instr at all in some of the application heavily used routines) which fixed the applications.

    Gil.

    Leave a comment:


  • Jim Seekamp
    replied
    Cliff, not sure what you are asking for...
    I'll email you the code again if that's what you want.
    In the meantime, I have created a dll just for the compression and compiled it in 9.01 and it works great, so I'm calling the dll. I just don't have time on my boss's dime to figure it out. (My error checks came up with nothing)

    Leave a comment:


  • Cliff Nichols
    replied
    Jim,
    I will be the 1st to admit that I should have used a copy instead of modifying what you sent me. (But hey, when looking for an answer sometimes we don't think ahead)

    Anyways, if you can send another copy with the code only looking at the file you are having problems with, and only the file in question, I think I may have found the problem.

    I threw my ErrorHandling routines at it just to see what might stick and although I have not had a chance to fully digest just what it is you are doing, I did trip into something (heck even got an idea for another error handling routine) but anyways what you want to hear is

    One hint though if my guess is right......Look at your compress function and your "comp_format&"

    I may be wayyyyy off though because I goofed and did not keep a copy of the original and just started modifying, so I may be the cause of what I might have found.

    Leave a comment:


  • Cliff Nichols
    replied
    Jim,
    If you can email it to [email protected] that would be great. Maybe I can spot something (or maybe one of my error-handler routines can)

    If not, then no time lost in a second pair of eyes.

    Leave a comment:


  • Jim Seekamp
    replied
    Sorry, Cliff -- it's just that I don't really want that code going out to everyone, since its my original code from the late 1990s, and it is an additional source of protection during installation of our main products...
    But I think I may have posted it in some form on the PB board in the early 2000s anyway, so I guess its not such a big deal LOL
    If you want I'll email it to you if you want to take a look.

    Leave a comment:


  • Cliff Nichols
    replied
    Nevermind, I see you posted while I was typing.......disregard this post

    Leave a comment:


  • Jim Seekamp
    replied
    Steve - try the files I posted in the previous post

    Leave a comment:


  • Steve Rossell
    replied
    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.

    Leave a comment:


  • Jim Seekamp
    replied
    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

    Leave a comment:


  • Jim Seekamp
    replied
    11
    Last edited by Jim Seekamp; 18 Nov 2009, 11:04 AM.

    Leave a comment:


  • Tom Hanlin
    replied
    I think that's "garbled"...?

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

    Leave a comment:


  • Jim Seekamp
    replied
    Try a large text file with a bunch of smaller ones. It doesn't work.
    Last edited by Jim Seekamp; 18 Nov 2009, 10:50 AM.

    Leave a comment:


  • Stanley Durham
    replied
    worked for me 9.02
    no errors

    be sure to try
    >> Brian Chirgwin >> #Register None
    Last edited by Stanley Durham; 18 Nov 2009, 10:42 AM.

    Leave a comment:


  • Jim Seekamp
    replied
    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.

    Code:
    
    
    Last edited by Jim Seekamp; 18 Nov 2009, 11:30 AM. Reason: took out the source code

    Leave a comment:


  • Michael Mattias
    replied
    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!!!!

    Leave a comment:


  • Brian Chirgwin
    replied
    Originally posted by Jim Seekamp View Post
    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.

    Leave a comment:


  • Jim Seekamp
    replied
    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

    Leave a comment:


  • Bob Zale
    replied
    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.

    Leave a comment:

Working...
X