Migration to 64-bit. Find corrupt pointers

[Igor]

Hi,

We're adapting an old 32-bit app for 64-bit. Mainly it works, but sometimes we get random SIGSEG errors due to corrupt pointers. We already found and fixed many cases when pointers were processed through Integer or DWORD that is not correct for 64-bit.

Is there any way to find all such cases? Some help from the compiler or memory manager?

The problem in a fact that many 64-bit pointers are located below 2GB address space. And wrong processing of pointers via Integer/DWORD/Cardinal doesn't reveal the dangerous problem. So when new pointers are being created above 2-3GB we face a problem (SIGSEG).

Currently we found one trick, at beginning of our program we call GetMem() for 4GB buffer and it shifts all new pointers above 4GB and I can see what doesn't work correctly and try to debug it.

Is it possible to temporarily adjust 64-bit memory manager to generate pointers in address space above 4GB ?

[440bx]

Is it possible to temporarily adjust 64-bit memory manager to generate pointers in address space above 4GB ?

If I were facing the problem you described, I'd do whatever I can to correct the code.  To do that, what comes to mind at this time is to create an AWK script that scans the source code for occurrences of typecasts, such as "integer(", "dword(", "absolute" and dereferences (")^") and possibly others depending on how the program is written.  Such a script would likely need to be refined to produce a usable list of potentially offending lines of code but, it seems like something worth a try.

It will probably be a bit tedious but, if you want the result to be "solid", there doesn't seem to be a way around inspecting all the potentially offending lines of code.  A carefully tested AWK script can probably produce such a list.

HTH.

[Igor]

Thanks for your advice. It's a lot of work, but I don't see another solution.

[440bx]

Thanks for your advice. It's a lot of work, but I don't see another solution.

You're welcome.  If I can think of something that is less work and also effective, I'll mention it but, for now, that's the only thing that comes to mind and, you're right, it will likely be a lot of work.

if you could post various pieces of code that suffer from the problem, anywhere from 1000 to 5000 lines, maybe looking at it would bring other ideas.

ETA: one thing that comes to mind is simply replacing all the occurrences of cardinal and dword with PtrUInt, that's fairly easy, should be safe (of course, to be safe and prudent, test it on a copy of the code) and can be automated.  At least for those two types, it should take care of the problem you mentioned.    The integer typecasts are definitely problematic because those are simply wrong in any bitness.

By replacing the occurrences of dword and cardinal with PtrUInt, that would make the list of typecasts to review smaller.

HTH.

[Thaddy]

It will always be a lot of work, but the refactoring options from either a Delphi or Lazarus IDE are your friend.

[Igor]

After hard work we catched several mistakes in the code. And now 64-bit app works correctly.