Page 2 of 3
Re: Random memory page errors causing crashing
Posted: Wed Feb 02, 2022 6:32 am
by DeanH
Hi Skywalk.
I checked the setups last year. The three schools have different versions of Windows 10. All Intel machines but different makes, CPUs, memory, etc. All are using a local area network in which the software is installed on a central server and shared. Desktop workstations access via a mapped drive letter and desktop icon - e.g. L:\Bm.exe . One school shifted the software to a workstation and shared it from there. Still happened. Even tried running it from the local C: drive. The frequency of "vanishing", as the users call it, reduced but did not cease. I have not seen a common element.
The weird thing is that this does not happen in 99% of other users and there are well over 1500 total. One of the librarians works in two schools, one in which it happens but it does not happen for the other.
There isn't a log. Is there a way to set that up? I am using OnError. The callback popups up a MessageRequester showing the error details. I have ticked the Purifier, Optimize code, Create threadsafe and Enable OnError lines. Recompiled everything many times. Have not been successful at getting the C-backend compiler to work, it hangs at a specific include. (If I compile just the include, it does not hang.) ASM no worries.
This is a great big fat mystery so far.
Re: Random memory page errors causing crashing
Posted: Wed Feb 02, 2022 9:22 am
by HeX0R
Does your app contain a (self made) DLL?
I had a similar problem a while ago, which in the end was a bug in one of my self made plugin DLLs.
Those are hard to catch, because an error in a DLL (same is true for Threads) will corrupt the stack most likely, and then it will be triggered just somewhere in your code (debugger or OnError, no matter).
From then on I always integrated a compiler flag to my codes, I can then compile debug versions, which include the source code of the DLL into the main program, calling all procedures directly (quite easy, since we have prototypes, you just have to take care to not use same global names or constants).
And then OnError triggered the correct line, and I finally saw, what (damn thing) I made wrong.
Re: Random memory page errors causing crashing
Posted: Fri Feb 04, 2022 1:43 am
by BarryG
DeanH wrote: Wed Feb 02, 2022 12:20 amI am now feeling the problem is caused by a background task.
I can almost guarantee it's not. Your story is almost exactly like my experience, where I had no idea what was causing it, for months and months. There's one little thing wrong in your code that's causing it. Finding it will be like finding a needle in a haystack, but you'll eventually nail it. Reading your posts in this thread is like reading my old posts with the same problem until I found it. I too used to shift the blame to some external thing causing it, but it wasn't.
DeanH wrote: Mon Jan 31, 2022 12:37 amIn only one case, the program was still in the Task Manager but not visible.
The only time I've seen this is when the user is logged in as Limited but the exe gets run as Admin for whatever reason. This can result in no window on the desktop, but the exe is seen in Task Manager. It happened to me.
Sometimes we also make the simplest of logic errors when coding. Here's one of mine ->
https://i.imgur.com/4ipz3Hf.png
As you can see, my app was sometimes referencing a non-existent window handle, which I had no idea about, and thus my exe kept crashing.
You can also use the
Windows Reliability Monitor tool to read info about exe crashes and general system instability, to see if that helps.
Re: Random memory page errors causing crashing
Posted: Mon Feb 07, 2022 10:27 pm
by DeanH
Been doing a lot of investigation about this. BarryG has been helping a lot, and I would like to thank him for his patience and contribution. I have set up OnError traps in the dozen exe's in my system and installed these with the few users having the problem. Results are appear random. Different places in the code, different statements, it even crashed on MessageRequester once. Sometimes it crashes without triggering the OnError callback. Never crashes at the same place twice. I wonder if it some type of stack overflow problem? Most of the errors (not all) are memory page errors. Is there any control I have over the size of the stack used by PureBasic compiled exe's when they are running? Or is this part of Windows? If so, can it be adjusted?
Re: Random memory page errors causing crashing
Posted: Mon Feb 07, 2022 11:49 pm
by mk-soft
A few points:
- Do you use threads or other asynchronous processing?
- Do you make changes to gadgets from threads?
- Do you allocate memory without checking if it is successful?
- Check if Dim, ReDim of array were successful
- Have compiler option ThreadSafe enabled.
- Do you protect access to lists, maps with mutex when using threads?
- Do you use EnableExplicit
- Do you check if load, create images, fonts, etc. was successful?
Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 1:45 am
by DeanH
Good questions.
- Do you use threads or other asynchronous processing?
- Do you make changes to gadgets from threads?
- Do you allocate memory without checking if it is successful?
- Check if Dim, ReDim of array were successful
- Have compiler option ThreadSafe enabled.
- Do you protect access to lists, maps with mutex when using threads?
- Do you use EnableExplicit
- Do you check if load, create images, fonts, etc. was successful?
Threads are not used.
I rarely allocate memory and if I do it is always checked.
No ReDim's. Many global Dim's but not checked. These are allocated at the start of the exe's. Would they be checked by testing their size?
ThreadSafe is enabled.
I have not used Enable Explicit. Is it a problem if variables have not been declared before use?
Windows, gadgets, images and fonts always checked. I make extensive use of IsGadget, IsImage, IsFont, IsWindow, etc.
There are over 200 source code files, over 20Mb. I used the DOS command Find to locate all .l instances and changed to .i where possible.
I have made use of a number of libraries from this forum. ListIconSort is one. PrinterLib, printing barcodes, PurePDF.
Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 7:35 am
by Shardik
Have you already read
freak's blog posting about testing 64-bit applications after conversion from 32-bit? You should also follow his link to a Microsoft article about 4-Gigabyte tuning with the hint to change a registry key in order to obtain addresses in the high 64-bit range with pointers which won't fit into the 32-bit range anymore. These will blow your application quickly and should help you in debugging your 64-bit version. With some luck your 64-bit app will become stable again. Did you experience the crashes already with your 32-bit version? Nevertheless you should try the temporary registry change to improve your 64-bit version.
Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 7:54 am
by Marc56us
DeanH wrote: Tue Feb 08, 2022 1:45 am
I have not used Enable Explicit. Is it a problem if variables have not been declared before use?
We realize how useful this command is when you spend hours (days) looking for what you think is a bug and it turns out to be just a typo (ie: I and l) in a variable name or errors between local, global, protected variables that make a variable change several times etc
Practically indispensable when you work with several sources.
For the initial post, ask users to also look at the windows events log at the time/minute of the crash:
Win + R
eventvwr (Windows Log: Application and System logs, check red and yellow icons)

Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 9:37 am
by Denis
Another way to explore
You have to control all predeclared structures with the Microsoft declarations
For example, LVITEM is not OK, already reported here (
https://www.purebasic.fr/english/viewto ... re#p560935).
I remember a crash with such bad structure size.
Maybe there are no reports, but everything must be eliminated as a possible cause.
I also create a file, and at the beginning of each procedure I record the name of the procedure and also the pb file in which it is located. After the recording, I close the file and if there is a problem, I look at the last procedure called but also the previous ones to try to see if memory pointers are used, Pb structures or personal.
It may have been said before, but it is almost always necessary to use .i variables, the .l, .a etc are only used in very specific cases.
Some Microsoft APIs are dangerous to use if they are not used properly.
Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 12:06 pm
by BarryG
Just wondering if "Return" can be used inside an If/EndIf block? The manual says nothing about not being able to, so I assume it's safe?
Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 3:41 pm
by mk-soft
You can use several ProcedureReturns in one procedure.
Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 9:44 pm
by BarryG
mk-soft, are you answering me? If so, I was asking about "Return", not "ProcedureReturn". Apparently Gosub/Return adds and removes to the stack, so I was wondering if using it inside "If/EndIf" affects the stack count.
Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 10:45 pm
by mk-soft
Very important !
PB-Help
If the command Goto is used within the body of a sub routine, FakeReturn must be used. FakeReturn simulates a return without actually executing a return, and if it is not used, the program will crash. Note: To exit a loop safely, Break should be used instead of Goto.
Example
Code: Select all
Gosub SubRoutine1
SubRoutine1:
...
If a = 10
FakeReturn
Goto Main_Loop
EndIf
Return
The functions Goto, Gosub, Return are on a red list for me. I never use them.
Re: Random memory page errors causing crashing
Posted: Tue Feb 08, 2022 11:00 pm
by BarryG
Yes, but I'm asking if "Return" can be used inside an If/EndIf block (not Goto or Gosub). Like this:
Code: Select all
; Even though this code is ugly/bad, is it safe to do?
condition=1
For n=1 To 1000
Gosub test
Next
Debug counter ; 1000
End
test:
If condition=1
counter+1
Return
EndIf
Re: Random memory page errors causing crashing
Posted: Wed Feb 09, 2022 3:20 am
by Demivec
BarryG wrote: Tue Feb 08, 2022 11:00 pm
Yes, but I'm asking if "Return" can be used inside an If/EndIf block (not Goto or Gosub).
Using "Return" in that manner is perfectly alright. If/EndIf blocks don't manipulate or use the stack.