Finding a bug when Purifier and line numbering doesn't help?

Everything else that doesn't fall into one of the other PB categories.
BarryG
Addict
Addict
Posts: 4128
Joined: Thu Apr 18, 2019 8:17 am

Finding a bug when Purifier and line numbering doesn't help?

Post 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. :(
User avatar
skywalk
Addict
Addict
Posts: 4211
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
User avatar
idle
Always Here
Always Here
Posts: 5836
Joined: Fri Sep 21, 2007 5:52 am
Location: New Zealand

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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
Bitblazer
Enthusiast
Enthusiast
Posts: 761
Joined: Mon Apr 10, 2017 6:17 pm
Location: Germany
Contact:

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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.
Last edited by Bitblazer on Tue Mar 05, 2024 12:31 am, edited 7 times in total.
BarryG
Addict
Addict
Posts: 4128
Joined: Thu Apr 18, 2019 8:17 am

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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.
User avatar
idle
Always Here
Always Here
Posts: 5836
Joined: Fri Sep 21, 2007 5:52 am
Location: New Zealand

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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 
BarryG
Addict
Addict
Posts: 4128
Joined: Thu Apr 18, 2019 8:17 am

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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.
User avatar
idle
Always Here
Always Here
Posts: 5836
Joined: Fri Sep 21, 2007 5:52 am
Location: New Zealand

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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?
BarryG
Addict
Addict
Posts: 4128
Joined: Thu Apr 18, 2019 8:17 am

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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.
juergenkulow
Enthusiast
Enthusiast
Posts: 581
Joined: Wed Sep 25, 2019 10:18 am

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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?
BarryG
Addict
Addict
Posts: 4128
Joined: Thu Apr 18, 2019 8:17 am

Re: Finding a bug when Purifier and line numbering doesn't help?

Post by BarryG »

Using "! int3" gets caught by the crash handler and reports this error:

Code: Select all

Error Desc : Breakpoint
Error Code : 0x2147483651
normeus
Enthusiast
Enthusiast
Posts: 470
Joined: Fri Apr 20, 2012 8:09 pm
Contact:

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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.
google Translate;Makes my jokes fall flat- Fait mes blagues tombent à plat- Machte meine Witze verpuffen- Eh cumpari ci vo sunari
User avatar
skywalk
Addict
Addict
Posts: 4211
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
tored
User
User
Posts: 86
Joined: Wed Feb 16, 2022 12:47 pm
Location: Sweden

Re: Finding a bug when Purifier and line numbering doesn't help?

Post by tored »

Silly idea, change to use OnErrorGoto instead of OnErrorCall and see if it catches the error.
tored
User
User
Posts: 86
Joined: Wed Feb 16, 2022 12:47 pm
Location: Sweden

Re: Finding a bug when Purifier and line numbering doesn't help?

Post 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?
Post Reply