Page 1 of 2
Finding a bug when Purifier and line numbering doesn't help?
Posted: Mon Mar 04, 2024 10:58 pm
by BarryG
So my main app is silently exiting on some people's PCs without warning. I've had the Purifier on and line numbering enabled, as well as a crash handler with "OnErrorCall(@CrashHandler())" set to it. But the handler never gets called, and my app just silently disappears from Task Manager. This happens regardless of whether an anti-virus is running as well, or if the app has been white-listed with it.
How do I even start to diagnose this? I'm so lost and it's depressing as hell as these are paid customers. I thought switching from 6.04 to 6.10 would help but it hasn't. I feel like giving up coding.

Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Mon Mar 04, 2024 11:07 pm
by skywalk
Usually that is the C compiler failing without prompt.
Compile with /commented and you will get the amalgamated line number to investigate.
Or compile asm with /commented.
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Mon Mar 04, 2024 11:56 pm
by idle
Have you checked the parameters and returns for imported functions?
I had to redo some imports recently which had been working on x64 think it was the returns
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 12:12 am
by Bitblazer
BarryG wrote: Mon Mar 04, 2024 10:58 pm
How do I even start to diagnose this?
The classic way is to insert debug output around the code sections where you suspect the crash/exit happens. Try to pin the action that happens shortly before the crash/exit and insert debug output and keep doing that till you know exactly which line is the last executed line.
I did that for a while, but the more complex the software gets (multiple threads involved, multiple software elements involved (client<->server), the more time consuming it gets. So i wrote a preprocessor that injects line numbers into the sources and wrote a socket tool to catch these sourcefile+linenumber calls and records them. That way, you get a pretty good clue about the last processed lines just before a software crashes.
The sources are some years old and have to be updated to be useable again, plus you need a decoder that parses the combinations of sourcefile+linenumber and creates a human readable output of all lines executed till the crash.
If you are willing to use this, you will find your bug. But the sources and documentation are unfinished and raw and some years old.
If i only had more time, this would have been released 5 years ago
ps: i never finished the tools because i was able to use the raw version to find all my mysterious crashes, so this method is pretty effective.
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 12:15 am
by BarryG
I don't use the C compiler. If I compile ASM with "/commented", how will that show me where the problem is?
I don't have many imported functions, but I've checked the parameters and returns for them and they seem okay.
The app doesn't crash; it just exits silently. Makes it hard to guess in over 60,000 lines of code. You wouldn't know it's not running anymore until you go to click its system tray icon, but that just disappears from the tray because the exe isn't running. An actual crash would be great because my app can catch that and show the source line, but it's not crashing.
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 12:55 am
by idle
How does it exit if it's not crashing or closed.
I'm guessing you're keeping track of gdi handles and not adding to many entries to a gadget
for a sanity check you could add a macro to replace allocatememory in case that fails anywhere
Code: Select all
Procedure _AllocateMemory(size,from.i)
Protected *mem = AllocateMemory(size)
If *mem
ProcedureReturn *mem
Else
MessageRequester("error","allocate failed line " +Str(from))
EndIf
EndProcedure
Macro AllocateMemory(size)
_AllocateMemory(size,#PB_Compiler_Line)
EndMacro
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 1:41 am
by BarryG
idle wrote: Tue Mar 05, 2024 12:55 amHow does it exit if it's not crashing or closed
Exactly the problem!

That's what I can't work out.
I did notice that I had this line of code:
Code: Select all
Prototype.l ProtoAccessibleObjectFromPoint(pt.q,*ia,*var)
Where the prototype is of long type. I changed it to ".i" (integer) and it still works. So maybe that's the cause?
Also, when using OpenLibrary(), should the variable that opens it be of integer type, too? Most of mine have no type set.
I don't have GDI handles, and all AllocateMemory() use is checked for non-zero before trying to use them.
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 2:53 am
by idle
BarryG wrote: Tue Mar 05, 2024 1:41 am
idle wrote: Tue Mar 05, 2024 12:55 amHow does it exit if it's not crashing or closed
Exactly the problem!

That's what I can't work out.
I did notice that I had this line of code:
Code: Select all
Prototype.l ProtoAccessibleObjectFromPoint(pt.q,*ia,*var)
Where the prototype is of long type. I changed it to ".i" (integer) and it still works. So maybe that's the cause?
Also, when using OpenLibrary(), should the variable that opens it be of integer type, too? Most of mine have no type set.
I don't have GDI handles, and all AllocateMemory() use is checked for non-zero before trying to use them.
Openlibray will be an integer and return an integer, in the case you use #PB_ANY
ProtoAccessibleObjectFromPoint is correct hrresult is a long and the parameters are ok
What about threads?
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 4:02 am
by BarryG
Threads: I use a lot and with thread safety on. All params seem correct because they're just one ".l" parameter that gets ignored really.
I did have this other code:
Code: Select all
GetCursorPos_(@CursorPos)
x=CursorPos\x
y=CursorPos\y
If AccessibleObjectFromPoint(y<<32|x,@*pIAcc,@vt)=#S_OK
; ...
EndIf
And I changed the "If" line to this in case it makes a difference with 6.04 vs 6.10:
Code: Select all
If AccessibleObjectFromPoint(PeekQ(@CursorPos),@*pIAcc,@vt)=#S_OK
But I'm not sure if that's necessary. It works both ways.
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 11:04 am
by juergenkulow
If you insert an error, e.g. ! Int3, in a procedure that runs as a thread, is the ErrorHandler executed correctly or does the program simply abort?
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 11:33 am
by BarryG
Using "! int3" gets caught by the crash handler and reports this error:
Code: Select all
Error Desc : Breakpoint
Error Code : 0x2147483651
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 12:44 pm
by normeus
Are you loading any system DLLs? I remember KCC had a problem with a program that was loading "Oleacc.dll" and it turned out that it was being loaded from an older copy another program in the path had installed. I say this because your program exits on some computers not all of them. Make sure you use full path for DLL OpenLibrary.
Norm.
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 4:11 pm
by skywalk
BarryG wrote: Tue Mar 05, 2024 12:15 am
I don't use the C compiler. If I compile ASM with "/commented", how will that show me where the problem is?
I strongly suggest you edit your codebase to compile with the C backend. The process will undoubtedly expose a problem in your code.
Yes, convert any ASM specific code to either standard PB or using the inline equivalents. The C optimizer will come very close if not exceed the ASM functions.
I assume all code uses EnableExplicit.
Add log entries, especially where your threads are working.
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 4:55 pm
by tored
Silly idea, change to use OnErrorGoto instead of OnErrorCall and see if it catches the error.
Re: Finding a bug when Purifier and line numbering doesn't help?
Posted: Tue Mar 05, 2024 4:58 pm
by tored
BarryG wrote: Tue Mar 05, 2024 4:02 am
Threads: I use a lot and with thread safety on.
No threads reading and writing to the same memory at the same time?
All GUI updates are done in the main thread?