Trig Tangent Bug (3884 version WP-34S)

[BarryMead]

If you compile the 3884 version of the WP-34s firmware and flash a REAL CALCULATOR with this firmware, it will display the word "Reset", or "Restored", if you attempt to take the tangent of the value .9999999 (7-9's) (Angle in Degrees mode). The emulator does not have any problem, so the issue is probably related to a stack overflow/corruption. The reset error occurs weather in normal or Double Precision mode.

I confirmed that it was NOT battery related by attaching the USB cable to my calculator's (Harald Pott's USB board), which ensures that 3.1 volts is ALWAYS available to power the CPU irrespective of battery condition.

If anyone in the forum has an ICE debugger and can evaluate stack problems, perhaps we can see what is causing this crash, or why the tangent function only fails with certain input values.
I found several other input values that cause the tangent function to reset crash as well. (1.9999999), (1.00000001), (2.9999999), (2.000000001), (3.99999999), (4.99999999)...
It seems to occur with values close to but not exactly integer numbers (I hope this is a valuable clue).

Thanks, Barry

[damaltor]

Does not crash (at least for me) on build 3869.

[emece67]

Mine work as reported by Barry.

Mi machine always reports "Reset", the stack and L registers remaining untouched. The (Qt) emulator works OK.

Regards.

p.s. perhaps this should be moved to the "official" wp3x bug thread.

[Paul Dale]

What firmware version?

3869 works.
3884 fails.

I'm running 3575 here and the bug isn't present -- I know I need to update, but my son ran off with & then disassembled the only Windows machine I had.


Pauli

[d b]

emece67;
re; Merging threads. That's a good idea, to keep the bug info in one place where it can be easily found. If one of the 34s team or the OP ask, I'll do that.

Pauli;
It sounds like your son is following in dad's footsteps. As long as he doesn't loose tiny screws in the carpet.....

[mendesp]

When I compiled the emulator on my pc and tried calculating tan(cos(sin(9))), I got this error message.

Run-time Check Failure #2 - Stack around the variable 'x' was corrupted.

As Barry suggested in another thread, something wrong happened when I compiled 3884 version on a my Windows computer with Visual C++ 2010. I got this error message:

storage.c(44): fatal error C1083: Impossible d'ouvrir le fichier include : 'unistd.h' : No such file or directory

I guess unistd.h is Unix related and not supported on Windows.

Is there a way to get around this issue ?

[BarryMead]

(02-25-2016 05:31 PM)mendesp Wrote:  I guess unistd.h is Unix related and not supported on Windows.

Is there a way to get around this issue ?

Pascal has always been able to compile windows versions of the emulator so there MUST be a way to configure a windows system to solve this issue. There is a file named README_QTGUI.txt in the trunk/QtGui directory of the SVN download that explains which dependencies are required to compile the Qt Emulator for the various platforms including windows.

I hope this helps, Barry

[BarryMead]

In an effort to NARROW DOWN the cause of this bug, I did an SVN checkout of the 3883 version of the WP-34S repository (One version older than the latest 3884 version) to see if this bug was happening on that version. I compiled a realbuild for that 3883 version and flashed my real calculator with that firmware, and it DID NOT exhibit the bug. So the bug was definitely caused after Paul Dale added the improvements to the trig function accuracy in the 3884 revisions. There may not be any logic errors or programming mistakes in this revision, but at least we now know for certain that this is when the bug first occurred, so it should be helpful in investigating the issue, as we can concentrate on only the changes between the 3883 and 3884 revision. It could be that the changes made caused the stack usage to exceed available stack space. If there is anyone on the forum that still has a working hardware debugger it would be helpful to see the bug happen in real time so we can gain a better understanding of what is going wrong, and how to approach a solution. At the moment it is difficult to find the bug since it does not present in the emulator.
I hope this helps, Barry

If you want to know how to grab a copy of the 3883 SVN version, this is how I did it.

svn checkout svn://svn.code.sf.net/p/wp34s/code -r 3883 wp34s-3883

This command will create a fresh SVN download of the 3883 version of the SVN repository and put it into a directory named wp34s-3883.

[emece67]

(02-25-2016 12:15 PM)Paul Dale Wrote:  What firmware version?

I cannot say. I use a local SVN repository whose versions do not match that of the official SVN repository.

I was able to reproduce the faulty behaviour on a machine I flashed today with a firmware version that contains the last patches for sin/cos/tan discussed these days in another thread ( here )

Unfortunately my SVN server is not working today due to the people at Synology trying to fix a problem on it, so I cannot revert to the previous version to check if the issue is present on it.

[Paul Dale]

Thanks Barry for nailing this down to my recent changes. I'll have a revisit when I get time and see if I can reduce the stack use -- the 31S code is fine stack wise but I'll have to validate the accuracy.

- Pauli

[pascal_meheut]

(02-25-2016 06:33 PM)BarryMead Wrote:  Pascal has always been able to compile windows versions of the emulator so there MUST be a way to configure a windows system to solve this issue.

It depends a lot on the #define and it is not always easy. But compiling either the Qt version or the original one relies on using the right set of tools, the exact same commands, etc.
Supporting a new compiler/environment is not really for beginners.

[Paul Dale]

I think I found it via code inspection. The increased size of the numbers in the tangent code path caused overflows which could impact the things badly.

I also uncovered a very subtle bug in the range reduction code where an interrupt had the potential to alter the conditional tests that determined the octants -- very unlikely and possibly not harmful but better fixed.

The down side is a eight more bytes of stack space for comparisons. I hope we've got the headroom for the matrix functions.

Barry, care to give this a go?


- Pauli

[BarryMead]

(02-26-2016 07:12 AM)Paul Dale Wrote:  Barry, care to give this a go?
- Pauli

Paul: I just tried the latest version 3886 from the SVN repository, and the bug is GONE!

I will continue to test this version, but I think you nailed it!

Thanks for addressing this issue so quickly.

Sincerely, Barry

[mendesp]

Thank you Paul. Everything is now working flawlessly.

Regards,

Patrick

[emece67]

(02-26-2016 07:12 AM)Paul Dale Wrote:  The down side is a eight more bytes of stack space for comparisons. I hope we've got the headroom for the matrix functions.

I've just tested this last patch and it works OK here. I've also tested some "heavy" matrix functions (\(M^{-1}\), Mx, DET & LINEQS) with the maximum allowed matrix sizes (9x9) without problems.

Thanks again & regards.

[Paul Dale]

Thanks for the matrix testing. I know we're right on the limit with these.

I'm not sure how close we are for the statistical distributions -- I suspect very again but I think we saved some RAM use with the xrom conversion. Inverse Chi^2 and F would be the test cases here, with F likely to be the worse.

Still, I'm happy with the patch.


- Pauli

[walter b]

We need an integration build by Marcus, don't we?

d:-?

[Marcus von Cube]

(02-27-2016 04:25 AM)walter b Wrote:  We need an integration build by Marcus, don't we?

d:-?

maybe later tonight...

EDIT: Done! 3887 is online.

[John Smitherman]

Quote:Done! 3887 is online.

Thanks Marcus. It loaded flawlessly.


John