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.
Finding a bug when Purifier and line numbering doesn't help?
Finding a bug when Purifier and line numbering doesn't help?
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.
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?
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.
Compile with /commented and you will get the amalgamated line number to investigate.
Or compile asm with /commented.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Finding a bug when Purifier and line numbering doesn't help?
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
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?
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.
Last edited by Bitblazer on Tue Mar 05, 2024 12:31 am, edited 7 times in total.
Re: Finding a bug when Purifier and line numbering doesn't help?
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.
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?
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
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?
Exactly the problem!
I did notice that I had this line of code:
Code: Select all
Prototype.l ProtoAccessibleObjectFromPoint(pt.q,*ia,*var)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?
Openlibray will be an integer and return an integer, in the case you use #PB_ANYBarryG wrote: Tue Mar 05, 2024 1:41 amExactly the problem!That's what I can't work out.
I did notice that I had this line of code:
Where the prototype is of long type. I changed it to ".i" (integer) and it still works. So maybe that's the cause?Code: Select all
Prototype.l ProtoAccessibleObjectFromPoint(pt.q,*ia,*var)
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.
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?
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:
And I changed the "If" line to this in case it makes a difference with 6.04 vs 6.10:
But I'm not sure if that's necessary. It works both ways.
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
Code: Select all
If AccessibleObjectFromPoint(PeekQ(@CursorPos),@*pIAcc,@vt)=#S_OK-
juergenkulow
- Enthusiast

- Posts: 581
- Joined: Wed Sep 25, 2019 10:18 am
Re: Finding a bug when Purifier and line numbering doesn't help?
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?
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?
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.
Norm.
google Translate;Makes my jokes fall flat- Fait mes blagues tombent à plat- Machte meine Witze verpuffen- Eh cumpari ci vo sunari
Re: Finding a bug when Purifier and line numbering doesn't help?
I strongly suggest you edit your codebase to compile with the C backend. The process will undoubtedly expose a problem in your code.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?
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.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Finding a bug when Purifier and line numbering doesn't help?
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?
No threads reading and writing to the same memory at the same time?
All GUI updates are done in the main thread?


