Crash with PB 6.10 b6 with function PeekS / PeekL

[DarkDragon]

I strongly disagree with this 'fix', your app will crash anyway if the target computer has a lot of memory. Accessing pointer with a long read on x64 is wrong and should be fixed, but if you like unstable apps, feel free to apply this kind of hacks.

Yes, this is no fix, but a workaround.
If he can't fix his code, he should stay with the old behavior of low address memory allocation.

You don't seem to understand. It's not even a workaround if it isn't guaranteed to work. It's just random that it works on your machine frequently.

[fryquez]

Daniel, please don't post such nonsense. What's your solution for Barry?
His posts make a total clear that he can't fix his code - and not even find the problematic locations in the code.

Avoid high memory addresses is bad, but what else can he do. Sticky with PB 6.04 forever?

[DarkDragon]

Daniel, please don't post such nonsense. What's your solution for Barry?
His posts make a total clear that he can't fix his code - and not even find the problematic locations in the code.

Avoid high memory addresses is bad, but what else can he do. Sticky with PB 6.04 forever?

Your workaround doesn't avoid allocation of memory with higher address regions, it just doesn't randomly relocate your addresses. If you have plenty of memory used you'll land in 64bit memory even with high entropy disabled. High entropy virtual addresses means you have chaotic addresses, but disabling it isn't implying you'll end up with only 32 bit addresses.

[fryquez]

High entropy virtual addresses means you have chaotic addresses, but disabling it isn't implying you'll end up with only 32 bit addresses.

That's right, but this feature is the main reason why his crashes occur with PB 6.10.

[Fred]

If you refer to this https://www.purebasic.fr/english/viewtopic.php?t=83721, it happens which 6.04 as well from what I understand

[BarryG]

Yeah, it's weird. I might have to avoid the line-numbering approach and write to a file when every procedure starts (as someone else said), so at least I can see which procedure the app "stopped" in. This will be annoying to code, though, as I have hundreds of procedures in different IncludeFiles.

@Fred: Maybe a future release can have the current procedure name recorded somewhere in the debugger, similar to how a line number is recorded for a crash?

[Fred]

There is some constants which can help you like #PB_Compiler_Procedure, #PB_Compiler_Filename, #PB_Compiler_Line

Code: Select all

Procedure MyProc()
  
  Debug #PB_Compiler_Procedure + " " +  #PB_Compiler_Filename + " " + #PB_Compiler_Line
EndProcedure

MyProc()

You can use a macro to ease the thing if you put this everywhere

[BarryG]

That looks interesting! Thanks for the idea, Fred. I will see what I can do with it. It gives me hope!