5.10b4 - 32bit app crashes on x64 OS

[jassing]

(I cannot use the debugger,whenver I try, the compiler crashes...)

I have a 32bit app that runs fine on 32bit os's -- and no errors have been reported from anyone using it.
However, when it's run on a 64 bit os, it gets somewhat random IMA errors, sometimes on a line of code (databaseupdate()) and others on a statement (endprocedure)

I cannot compile it as a 64 bit app, it relies on EOL dll's that are only available for 32bits.

Has anyone run into similar problems, or has a clue where I can start to look for "the problem"? No, I cannot post the entire program, dll's etc -- nor have I 'narrowed it down', 142,000 lines of code -- I'm hoping for a general "look over there 1st" sort of thing.

[IdeasVacuum]

It is mostly likely memory access and may not be your code at all but a DLL you are using.....

If the code is oldish there are a few things people may point to (no pun intended), like the API functions Get/SetWindowLong_(), which should be Get/SetWindowLongPtr_().

(I cannot use the debugger,whenver I try, the compiler crashes...)

That is the most scary bit, it should be your number 1 target. Do you mean you cannot use PB 32bit on a 64bit PC with the debugger or you can't use the debugger on any PC with this specific code?

[jassing]

If I build the app on a 32bit os (Not run, F5, but Compiler->build target->target) I can run the app on any 32bit os.

If I take this 32bit exe to a 64bit os, the 64bit os will crash with IMA errors in seamingly random spots.

On a 32bit os, if I try to run it with the debugger or w/in the IDE, the compiler crashes. (I get a notice that hte compiler has crashed) -- It appears to crash at the very end of compiling.

Now it gets weird -- I transfered all the sources to a 64bit os; ran 32bit version of PB 5.10b4; and built the exe --
SOMETIMES, the compiler crashes right away, SOMETIMES it will crash towards the end, but Sometimes, it builds an exe that runs on x64 w/o issues. (it will then also run on a 32bit OS, when it successfully compiles w/o crashing)

On 64 bit os, 32bit PB, if I try to run (f5) sometimes the compiler crashes at the very beginning of compile, other times at the end.. but the compiler always crashes.

[luis]

On a 32bit os, if I try to run it with the debugger or w/in the IDE, the compiler crashes. (I get a notice that hte compiler has crashed) -- It appears to crash at the very end of compiling.

Are you telling me you wrote a program (142,000 lines) without ever being able to execute it with the debugger enabled ?

I think the answer is no and that the behavior you are reporting started at some point, or maybe switching the compiler version. Right ?

In that case I would go back to that point and investigate what happened there, try my program with the purifier, etc.

[jassing]

On a 32bit os, if I try to run it with the debugger or w/in the IDE, the compiler crashes. (I get a notice that hte compiler has crashed) -- It appears to crash at the very end of compiling.

Are you telling me you wrote a program (142,000 lines) without ever being able to execute it with the debugger enabled ?

no. That's what the program is now, adding a report writer (that is effectively dead), linking against its lib causes the compiler to crash....

Using the lib in "test program" does not-- so somewhere in 142000 lines of code is something, that when combined with linking against the report writer's lib, causes the compiler to crash.

But your point is taken, the compiler crashing is completely understrandable.... The compiler crashes regardless of pb version back to 4.6.

[IdeasVacuum]

.... Try the Compiler Syntax Check (PB v5.10). Also, if you have UltraEdit or NotePad++, try searching for the report writer's function names (find string) to see if one of your function names matches (or "almost" matches - i.e. the wrong function is inadvertently called). If you have access to the lib's source code, you can check for things like non-protected vars in procedures that have the same name as global vars in your code -that is the sort of thing that can give sporadic errors at run time.

Concerning the compiler crashing, I would comment-out all the report writer lib functions, then un-comment them step by step to try to catch the point where the compiler crashes.

For run-time testing, you could stream output to a log file, indicating the active function and var values - when the app crashes, the log may reveal something unexpected.

[Fred]

The compiler should never crash, if you can please send us your program so we can investigate.

[IdeasVacuum]

please send us your program so we can investigate.

Grab that offer with both hands jassing