Author Topic: Bug Reports  (Read 465415 times)

0 Members and 1 Guest are viewing this topic.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Bug Reports
« Reply #1980 on: August 14, 2016, 04:57:30 pm »
I think I found another!
inData(t ,data) throws error wrong number of args.
The token sign followed by a space is what breaks it. Any other character than a space compiles without error.
It appears to break when "t " is used in any argument for a command but the last. Line(t ,5,5,5) errors while Line(5,5,5,t ) compiles fine.

I don't know if this counts but the memory locations for the parametric tokens differ form Axe to Axe.inc.

Edit: Found another, this time in 1.3.0 downloaded from about a year ago. Subtraction with both of the arguments variables in memory brackets cause an incorrect answer. For example:
:L1->A
:Disp {A}-{A} >Dec
Gives an incorrect answer, but :Disp {L1}-{L1} >dec is correct. :{A}-{L1} gives the correct answer.
« Last Edit: August 14, 2016, 06:10:41 pm by E37 »
I'm still around... kind of.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1981 on: August 14, 2016, 06:09:41 pm »
Thanks for the reports, I have noted the issues in my todo list.

Offline neuronix

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 108
  • Rating: +0/-0
    • View Profile
Re: Bug Reports
« Reply #1982 on: August 24, 2016, 08:26:37 am »
The Axe application in 1.3.0 version is stable?

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1983 on: August 24, 2016, 01:20:36 pm »
The Axe application in 1.3.0 version is stable?

Definitely not. I "released" it outside of the updates thread because I expected stuff to be broken and wanted to crowdsource the bug finding process. And stuff was definitely broken, including some rather important things like backups and compilation of all but the simplest mathematical expressions.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Bug Reports
« Reply #1984 on: August 24, 2016, 03:00:48 pm »
The Axe application in 1.3.0 version is stable?

Definitely not. I "released" it outside of the updates thread because I expected stuff to be broken and wanted to crowdsource the bug finding process. And stuff was definitely broken, including some rather important things like backups and compilation of all but the simplest mathematical expressions.
It isn't that bad Runner. I compiled my 10000b program and only noticed the byte comparison bug I mentioned earlier.
I'm still around... kind of.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Bug Reports
« Reply #1985 on: September 17, 2016, 06:27:59 pm »
Got another one!  ;D
I'm not sure if this is Axe's fault though.
When using zStart to compile from within a program (ON +sto/zoom/trace) and that program is archived AND has the same name output name, Axe throws UNKNOWN ERR and quits. It deletes the source code (that's in archive probably because it tried to compile, deleted the program with that output name and then errored)
How to reproduce: (have zStart installed)
prgmBOB:
:.BOB
:
Then archive BOB. Edit it with zStart. Then press one of the compile key shortcuts. Axe will throw UNKNOWN ERR and quit. prgmBOB will be deleted.
Again, I don't know who's fault this bug is, but it almost took a library file that I was creating. Any ideas @Runer112 ?
I'm still around... kind of.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1986 on: September 17, 2016, 06:32:18 pm »
What version of Axe does this occur in?

Regardless, this bug doesn't seem too surprising, but it's mostly Axe's fault. I've made a note to fix it.


EDIT: Upon further inspection, this is zStart's fault. For some reason, it takes it upon itself to delete the output program before invoking Axe, but unlike Axe, it doesn't check if the output and input names are the same. So I'm not too concerned with any buggy behavior that stems from bad API call input.
« Last Edit: September 17, 2016, 06:46:54 pm by Runer112 »

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Bug Reports
« Reply #1987 on: September 29, 2016, 01:45:26 pm »
... And I'm back! With more bugs! As always, I am using 1.2.2a! @Runer112
The first one isn't really a bug but more of an unexpected feature. p2 found this one. Interrupts can occur in the middle of commands like Output(x,y,expr) and if that interrupt changes the location of the cursor, then the Output command will display at the end of where the interrupt left the cursor. I'm not sure if you want to do anything about it or just leave it.

I found the other bug, and it is a bug for sure. Compiling :5 and {Y1}r will compile normally, but on zoom compile it will throw error: undocumented. The five can be replaced with any number and the 'and' can be replaced with any bit-wise command (including the 2 byte plot token ones). The file must have the r after it and be the second argument. In all of the cases normal compile will not error but zoom will.
I'm still around... kind of.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1988 on: September 29, 2016, 01:47:42 pm »
... And I'm back! With more bugs! As always, I am using 1.2.2a! @Runer112
The first one isn't really a bug but more of an unexpected feature. p2 found this one. Interrupts can occur in the middle of commands like Output(x,y,expr) and if that interrupt changes the location of the cursor, then the Output command will display at the end of where the interrupt left the cursor. I'm not sure if you want to do anything about it or just leave it.

I found the other bug, and it is a bug for sure. Compiling :5 and {Y1}r will compile normally, but on zoom compile it will throw error: undocumented. The five can be replaced with any number and the 'and' can be replaced with any bit-wise command (including the 2 byte plot token ones). The file must have the r after it and be the second argument. In all of the cases normal compile will not error but zoom will.

The first thing isn't a bug. It's the programmer's responsibility to ensure thread-safety. :P

The second thing, I've recorded on the to-do list and will investigate (eventually).

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Bug Reports
« Reply #1989 on: December 06, 2016, 05:39:32 pm »
Ok. I think I have found another. (I'm not sure what's causing it)
I have found that recompiling a certain app causes flash corruption. I'm not 100% sure but it has happened 2 times in a row.
It does use hooks and inline assembly but I have used similar programs without mishap.

Since I need to reset my calc anyway I figured I will try to figure out what is causing it. (I'm sure it is Axe since I haven't been using assembly recently and I have been using the same apps for a year and they never showed any problems)
Oh, and it is 1.2.2a as always.
I'm still around... kind of.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1990 on: December 06, 2016, 06:11:51 pm »
Ok. I think I have found another. (I'm not sure what's causing it)
I have found that recompiling a certain app causes flash corruption. I'm not 100% sure but it has happened 2 times in a row.
It does use hooks and inline assembly but I have used similar programs without mishap.

Since I need to reset my calc anyway I figured I will try to figure out what is causing it. (I'm sure it is Axe since I haven't been using assembly recently and I have been using the same apps for a year and they never showed any problems)
Oh, and it is 1.2.2a as always.

Nothing immediately comes to mind as a possible reason for this. I think the only way I'd be able to reliably track down a bug like this would be if I could reproduce the bug in an emulator and actively debug it. However, it seems likely that your specific code and/or calculator environment may have something to do with it, as I haven't heard other reports, so reproducing it from scratch would be difficult.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Bug Reports
« Reply #1991 on: December 13, 2016, 06:27:33 pm »
Found another! (1.2.2a)
If you use the increment or decrement command on a single byte variable it returns odd values in hl.
0->A
Disp Ar++>Dec
This code displays a weird number. (NOT 1!)
It occurs with any one byte variable variables like {oA}--
The variable's value is changed correctly, only the value left in hl is wrong.

Edit: It turns out that it just returns the pointer instead of the value.
{Ar++} returns the expected value.
« Last Edit: December 13, 2016, 06:33:46 pm by E37 »
I'm still around... kind of.