Page 1 of 2

Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sat Mar 09, 2024 5:53 pm
by 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

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sat Mar 09, 2024 5:57 pm
by Fred
You should use PeekI(), no ?

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sat Mar 09, 2024 5:59 pm
by NicknameFJ
Hello Fred,

thank you for your fast reply.

My fault, you´re right, sorry.

NicknameFJ

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 2:17 am
by BarryG
Fred wrote: Sat Mar 09, 2024 5:57 pmYou 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?

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 9:11 am
by Fred
BarryG wrote: Sun Mar 10, 2024 2:17 am
Fred wrote: Sat Mar 09, 2024 5:57 pmYou 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

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 9:30 am
by STARGÅTE
BarryG wrote: Sun Mar 10, 2024 2:17 am 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)

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 9:40 am
by BarryG
Fred wrote: Sun Mar 10, 2024 9:11 amJust 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.
STARGÅTE wrote: Sun Mar 10, 2024 9:30 amPeekL() 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

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 10:00 am
by HeX0R
BarryG wrote: Sun Mar 10, 2024 9:40 am 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!

BarryG wrote: Sun Mar 10, 2024 9:40 am 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

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 10:08 am
by 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. :(

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 10:16 am
by STARGÅTE
BarryG wrote: Sun Mar 10, 2024 9:40 am 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.
BarryG wrote: Sun Mar 10, 2024 9:40 am 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.
BarryG wrote: Sun Mar 10, 2024 9:40 am 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.

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 10:18 am
by 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

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 10:20 am
by BarryG
Okay, thanks for the info. Same to STARGÅTE.

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 10:59 am
by 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

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 11:15 am
by 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.

Re: Crash with PB 6.10 b6 with function PeekS / PeekL

Posted: Sun Mar 10, 2024 5:49 pm
by fryquez
Fred wrote: Sun Mar 10, 2024 11:15 am 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.