Crash with PB 6.10 b6 with function PeekS / PeekL

[NicknameFJ]

Hello,

I wanted to create a list of installed printers.

Up to PB 6.04 with ASM and C backend it worded fine with the following code.
But with 6.10 beta 6 it crashs with both backends in line 15 with the PeekS / PeekL function

WIN 10 X64

Code: Select all

NewList Printers.s()

ClearList(Printers())  
enumFlags = #PRINTER_ENUM_LOCAL | #PRINTER_ENUM_CONNECTIONS
If EnumPrinters_(enumFlags, #Null, 1, 0, 0, @deviceNamesBufferSize, @printerCount) = 0
  deviceNamesBuffer = AllocateMemory(deviceNamesBufferSize)
  If deviceNamesBuffer And EnumPrinters_(enumFlags, #Null, 1, deviceNamesBuffer, deviceNamesBufferSize, @sizeRDB, @printerCount)
    If printerCount
      pInfoNameOffset = OffsetOf(PRINTER_INFO_1\pName)
      For i = 0 To (printerCount - 1)
        AddElement(Printers())
        
        Debug deviceNamesBuffer + i * (SizeOf(PRINTER_INFO_1)) + pInfoNameOffset
        
        Printers() = PeekS(PeekL(deviceNamesBuffer + i * (SizeOf(PRINTER_INFO_1)) + pInfoNameOffset))
      Debug Printers()  
      Next
    EndIf
    FreeMemory(deviceNamesBuffer)
  EndIf
EndIf   

Greetings
NicknameFJ

[Fred]

You should use PeekI(), no ?

[NicknameFJ]

Hello Fred,

thank you for your fast reply.

My fault, you´re right, sorry.

NicknameFJ

[BarryG]

You should use PeekI(), no ?

How do we know when we need to change from PeekL() to PeekI() with 6.10? My app is still exiting silently with no error messages and I have PeekL() all over the place from various snippets shared by others. I wonder if any of those are the cause?

[Fred]

You should use PeekI(), no ?

How do we know when we need to change from PeekL() to PeekI() with 6.10? My app is still exiting silently with no error messages and I have PeekL() all over the place from various snippets shared by others. I wonder if any of those are the cause?

You need a PeekI everywhere where you peek on a memory pointer (or address). Just post some snippet of you are unsure

[STARGÅTE]

How do we know when we need to change from PeekL() to PeekI() with 6.10?

Just to be clear here, this is no change because of PB 6.10.
Also in all previous versions of Pure Basic, PeekL() was never the right choice when looking for a memory address.
That your application has never crashed before, is pure luck.

PeekL() is from an age of PureBasic where only x86 (32 bit) compilation was possible, so before PB 4.3 (2008)

[BarryG]

Just post some snippet of you are unsure

I can't because the app doesn't "crash" as such; the process just ends silently. There's no way to know when it's going to happen. But I think I'll just search and replace all PeekL() with PeekI() and monitor how it goes.

PeekL() was never the right choice when looking for a memory address.

I was using other people's code from these forums and they used PeekL() in them. One example is ts-soft's Registry module, which was later updated by HeXOR (https://www.purebasic.fr/english/viewto ... 11#p488711). Were they both wrong to use PeekL() in it?

I also have this in my code a lot... can I safely change it to use PeekI() instead?

Code: Select all

procid=PeekL(@Proc32\th32ProcessID)

If I put this at the start of my code, it'll do the job while I monitor the situation, right?

Code: Select all

Macro PeekL(text)
  PeekI(text)
EndMacro

[HeX0R]

I was using other people's code from these forums and they used PeekL() in them. One example is ts-soft's Registry module, which was later updated by HeXOR (https://www.purebasic.fr/english/viewto ... 11#p488711). Were they both wrong to use PeekL() in it?

No!
PeekL is used only here:

Code: Select all

Case #REG_DWORD
				If *Ret <> 0
					*Ret\DWORD = PeekL(*lpData)
					*Ret\SIZE  = SizeOf(Long)
				EndIf
				result = Str(PeekL(*lpData))

And a DWORD is a long!

I also have this in my code a lot... can I safely change it to use PeekI() instead?

Code: Select all

procid=PeekL(@Proc32\th32ProcessID)

Such questions doesn't make much sense, you have to look into the structure to know which size an element has.
Here:
https://learn.microsoft.com/en-us/windo ... 32snapshot

[in] DWORD th32ProcessID

[BarryG]

But that's different to what STARGÅTE said, who said PeekL() was always wrong to use with 64-bit. I'm so confused.

[STARGÅTE]

I was using other people's code from these forums and they used PeekL() in them. One example is ts-soft's Registry module, which was later updated by HeXOR (https://www.purebasic.fr/english/viewto ... 11#p488711). Were they both wrong to use PeekL() in it?

It depends on the context of usage.

PeekL reads exact 4 bytes from a memory address.
So code parts like

Code: Select all

			Case #REG_DWORD
				If *Ret <> 0
					*Ret\DWORD = PeekL(*lpData)

are right and must keep PeekL(). A PeekI() here would lead to an invalid memory access, because it reads 8 bytes on 64 bit compilations.

I also have this in my code a lot... can I safely change it to use PeekI() instead?

Code: Select all

procid=PeekL(@Proc32\th32ProcessID)

No. The th32ProcessID is a DWORD, a Long in PureBasic. PeekL() is right.

If I put this at the start of my code, it'll do the job while I monitor the situation, right?

Code: Select all

Macro PeekL(text)
  PeekI(text)
EndMacro

No. As i said before. It is no simply replace. You have to go through your whole code step by step and check each PeekL() if it tries to read an address, because an address can be 4 byte or 8 byte depending on compilation target.

Edit: Please quote me correct. I said: "PeekL() was never the right choice when looking for a memory address."
PeekS() expects a memory address. If such an address in some were in another memory location, use PeekI() to receive the whole number.

[HeX0R]

STARGÅTE said:

when looking for a memory address

Your registry example looks for the content at a memory address!

And your second example is strange anyway, but I don't know the rest of the code.
If you are looking for the ProcessID, this should do:

Code: Select all

procid = Proc32\th32ProcessID

[BarryG]

Okay, thanks for the info. Same to STARGÅTE.

[fryquez]

You could disable 64-bit-ASLR.
You code will still be wrong, but your crashes with PB 6.10 should disappear.

Code: Select all

Import "/HIGHENTROPYVA:NO" : EndImport

[Fred]

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.

[fryquez]

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.