When the debugger crashes...

Trond · Post by **Trond** » Sat Aug 12, 2006 1:19 pm

When the program crashes with the debugger enabled you must switch
to another source and back before you can "kill" the already crashed
program. This is very inconvenient when trying to isolate the cause of the problem, so I suggest it be changed in future versions of the IDE.

Post by **freak** » Sat Aug 12, 2006 10:13 pm

What exactly do you mean by crashing ?
Do you mean an error such as "Invalid Memory Access" that is catched
by the debugger, or a downright crash without the debugger noticing ?

In the first case, the "kill" should work immediately. (at least it does here)

If it is the second case, then i'd like to know how to cause that, because
theoretically the debugger should catch any error.

Trond · Post by **Trond** » Sun Aug 13, 2006 9:43 am

I mean a downright crash without the debugger noticing. And I can't reproduce it just now, but three days ago I could (very strange).

Trond · Post by **Trond** » Sun Aug 13, 2006 12:35 pm

I can crash the program without the debugger noticing it in PB 3.94 but that is after the program has started (so the kill command works). The problem a few days ago was that the program crashed before the "the program is running" message appeared in the error log.

To reproduce the problem in 3.94 I simply run the terrain example with the AddMaterialLayer() line not commented out. (In 4.0 the terrain example does not work because LoadTexture() always returns 0.)

Trond · Post by **Trond** » Tue Aug 15, 2006 3:42 pm

I just noticed it's a similar problem with the "restart compiler" item. If the compiler crashes you can't restart it "because it is working".

Fluid Byte · Post by **Fluid Byte** » Tue Aug 15, 2006 4:17 pm

In 4.0 the terrain example does not work because LoadTexture() always returns 0.

I had the same problem with textures as I was converting some PB 3.94 > 4.00 code. Don't know if you already did but you need to specify the texture path with 'Add3DArchive()' to fix this.

Trond · Post by **Trond** » Tue Aug 15, 2006 4:35 pm

Fluid Byte wrote:
In 4.0 the terrain example does not work because LoadTexture() always returns 0.
I had the same problem with textures as I was converting some PB 3.94 > 4.00 code. Don't know if you already did but you need to specify the texture path with 'Add3DArchive()' to fix this.

If you don't know if I already did it you can check whether the terrain example does it.

By the way, here is the source that now (yet again) causes the program to crash without the debugger noticing:

Code: Select all

Procedure A()
EndProcedure
Procedure B()
EndProcedure
Procedure C()
EndProcedure
Procedure D()
EndProcedure
Procedure F()
EndProcedure
Procedure G()
EndProcedure
Procedure H()
EndProcedure
Procedure I()
EndProcedure
Procedure J()
EndProcedure
Procedure K()
EndProcedure
Procedure L()
EndProcedure
Procedure M()
EndProcedure
Procedure N()
EndProcedure
Procedure O()
EndProcedure
Procedure P()
EndProcedure
Procedure Q()
EndProcedure
Procedure R()
EndProcedure
Procedure S()
EndProcedure
Procedure T()
EndProcedure
Procedure U()
EndProcedure
Procedure V()
EndProcedure
Procedure W()
EndProcedure
Procedure X()
EndProcedure
Procedure Y()
EndProcedure
Procedure Z()
EndProcedure

Procedure AA()
EndProcedure
Procedure BB()
EndProcedure
Procedure CC()
EndProcedure
Procedure DD()
EndProcedure
Procedure EE()
EndProcedure
Procedure FF()
EndProcedure
Procedure XXX()
EndProcedure
Procedure XXY()
EndProcedure

Procedure Dummy()
  A()
  B()
  C()
  D()
  F()
  G()
  H()
  I()
  J()
  K()
  L()
  M()
  N()
  O()
  P()
  Q()
  R()
  S()
  T()
  U()
  V()
  W()
  X()
  Y()
  Z()
  AA()
  BB()
  CC()
  DD()
  EE()
  FF()
  XXX()
  ;XXY()
EndProcedure

Fluid Byte · Post by **Fluid Byte** » Tue Aug 15, 2006 6:26 pm

If you don't know if I already did it you can check whether the terrain example does it.

Well, I thought it was a programm of yours and not an PB 4.0 example. Haven't checked these yet. But why should I test this? You were pointing out that you have problem with 'LoadTexture()' and I tried to provide a solution for this.

However, I tested the example and it works without a flaw. Just like the code you posted. I ran it multiple times, set debugger on/of or restarted compiler. No matter how you do it, it won't crash and always lets you kill the execution on the first try. At least this is the situation for me.

Trond · Post by **Trond** » Tue Aug 15, 2006 8:56 pm

I don't know if it helps to reproduce the problem, but here's my preferences file: http://home.no.net/tsg1zzn/PureBasic.prefs

Trond · Post by **Trond** » Fri Aug 25, 2006 2:26 pm

This also makes the program crash and debugger doesn't notice anything:

Code: Select all

res64.q = 1
b32 = 10

res64 = (res64 * b32) % m32

Trond · Post by **Trond** » Wed Aug 30, 2006 5:33 pm

When you run this program the process ends but the debugger doesn't notice anything:

Code: Select all

Procedure.l IsPrime(A.q)
EndProcedure

For a = 0 To 7
  z + IsPrime(a)
Next
MessageRequester("", "Finished")

Post by **freak** » Wed Aug 30, 2006 5:59 pm

The first one with the many procedures seems fine here. I cannot find anything wrong with it.

The second one has the problem here as well, i will check that.

The third works here, but it ends with a different stack offset
than it started with, so there is definately something wrong there.

Trond · Post by **Trond** » Wed Aug 30, 2006 6:12 pm

Yes, that with the many procedures is just strange. Today it works as expected, some days it does not. I can't remember why I didn't get the asm output when it didn't work and compared to the asm output when it works.

Trond · Post by **Trond** » Sat Jan 26, 2008 10:46 am

Code: Select all

MultiByteToUnicode_(1251, 0)

The program ends, the debugger doesn't notice it, and if you try to run the program again it will use the standalone debugger. To use the integrated debugger again you need to close and re-open the file.