Unrecoverable crash to lock-up - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: Unrecoverable crash to lock-up (/thread-125592.html) |
Unrecoverable crash to lock-up - John Wasilewski - 10-02-2007 Anyone seen this problem?
Unrecoverable crash problemCausing total loss of all previous software development work In final tweak/adjust/debug stage, XEQuting a 473-line program caused the screen and keyboad to freeze. None of the keystroke combination reset procedures in the manual worked.
i.e. neither of the following freed the lock-up.
Consequences were very bad. I had to stick a pin in the back. Hoping that this was just an unfortunate rare occurrence, I re-typed the entire 473-line program from notes I had kept. When I tried to XEQute it again to resume where I had left off, it worked partially as before and then at exactly the same place in the data entry, exactly the same problem happened again. I'm therefore faced with having to type it all in yet again (that is, AT LEAST one more time, and probably more than one). Naturally, I'll try stepping through it next time, but when it crashes again, I will again be back to zero. This is very exasperating and time-wasting. It is also extremely discouraging. I had planned to build up gradually (and post to this site) a library of most-useful structural engineering code that would just lie in memory, preserved by always having a spare battery pair and replacing batteries carefully. This unrecoverable crash means I can expect to lose the lot. And that is a big big disincentive to software development on a system I can't trust, that has no possibility for external filesaves.
John Wasilewski Re: Unrecoverable crash to lock-up - Arne Halvorsen (Norway) - 10-02-2007 And on what machine did this happen?
Re: Unrecoverable crash to lock-up - Randy - 10-02-2007 My semi-educated guess: 35S And some wonder why others want still 41's, 67's and 97's. It's those blasted silly little magnetic cards... oops, forgot the 65.
IMO, the 35S is not a "system". Edited: 2 Oct 2007, 11:56 a.m.
Re: Unrecoverable crash to lock-up - Arne Halvorsen (Norway) - 10-02-2007 Yep must be, checked the manual.
I wonder how much more expensive the bug would had been with the simplest form of I/O (USB or memory card) for program backup...
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-02-2007 It happened/happens on an HP35s. Re: Unrecoverable crash to lock-up - Patrick Rendulic - 10-02-2007 Is it the HP35-scientific or the HP35-s*** ? I may be very rude, but at this stage, the HP-35 cannot be trusted. There seem to be to many bugs or "undocumented features". Maybe most problems will get fixed, but that means replacing the calculator.
Nevertheless I hope that the given problem will be solved!
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-02-2007 Good guess, Randy, it is a 35S. Also, you may be right that I shouldn't refer to it as a 'system' and I'm grateful to you for the comment. Please note, however, that I posted the original message because I have a fairly major problem here, that I really do need some solid help with if I can possibly find it, so I hope everyone won't mind, and no-one will be offended, if I ask that we keep focused on the technical problem, and avoid side issues like this. In particular, 1) Has anyone else had any similar experience? 2) Does anyone have any ideas of what type of code might cause it, so that I can search through my code to try to find MY bug? 3) Has anyone any ideas about how to force a non-destructive reset when the instructions in the manual don't succeed? Be in no doubt, if this problem persists and we can't find out why then the HP35S, which is otherwise a superb calculator, becomes totally crippled for all serious users. You can't write serious programs on a "calculator-that-isn't-a-system" (!) if there is no save facility AND occasional crashes wipe all programming you have ever done.
I see this as very, very important. Re: Unrecoverable crash to lock-up - John Wasilewski - 10-02-2007 Its the brand-new just-launched shiny new
Thanks for your encouragement and hopes for a solution Patrick, Re: Unrecoverable crash to lock-up - John Wasilewski - 10-02-2007 I have sent a detailed description of this problem to the calculators section of http://wwemail.support.hp.com and my report has been acknowledged by an autogen email from HP Calculator E-mail Support <calculator_support_en@mail.support.hp.com> with reference number KMM20282596V46293L0KM. I'll pass on anything useful or otherwise I manage to obtain from HP. If anyone would like to see the 473-line code that caused this, just let me have an email address to send it to you. I have a PC .txt file of it. The program does a rigorous parabolic-rectangular stress-block analysis of a rectangular RC section for a required moment of resistance in accordance with BS8110:Pt1:1997. It then recommends a section size (for the user to over-ride with his/her own choice), and, finally, optimises the compression and tension reinforcement bar sizes for minimum steel weight in the user's chosen section size.
---- Way to go! - Arne Halvorsen (Norway) - 10-02-2007 That was a novel idea! Actual complain to HP about 35s problem.
Anybody actual did that regarding the vector-syntax bug? Perhaps I should, thats *my* beef the with thing... Have not had to reset the 'system' though...., Mr. Wasilewski has my symphaties... Edited: 2 Oct 2007, 2:03 p.m.
Re: Unrecoverable crash to lock-up - Seth Morabito - 10-02-2007 If possible, I would also suggest trying to bring this up directly to Cyrille de Brebisson. I know he reads the Usenet newsgroups, and he may read this board as well. He is very keen on documenting and fixing all the bugs in the 35s, as we discussed at HHC, although of course due to the rest of HP being involved, he cannot comment on exactly what bugs may get fixed, nor when they will get fixed. But I know he is personally invested in the 35s and wants to see it bug-free. Googling for his name is probably a good way to get his contact information. He'll want to see the program that causes the lock-up, I'm sure. Regards,
Seth
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-02-2007 Thank you Seth.
to cyrille_de-brebisson@hp.com
HP 35s Scientific calculator Someone on the HP calculators users' forum at www.hpmuseum.org has suggested that I write to you about what may be a very serious fault with the seemingly excellent HP35s. I'm told you will certainly want to know about this. I short, I may have discovered a system instability causing occasional unrecoverable crashes, under as-yet unknown circumstances. The gravity of this comes from the fact that, with no means of saving programs, crashes needing a hard reset (causing total memory erasure) will make it untenable to develop serious software because one loses everything. All software that a user has ever developed is lost. Here's what has happened to me. In final tweak/adjust/debug stage, XEQuting a 473-line program caused the screen and keyboad to freeze. None of the keystroke combination reset procedures in the manual worked.
i.e. neither of the following freed the lock-up. Consequences were very bad. I had to stick a pin in the back. I therefore lost not only this long program but also ALL other code I had entered for previous programs. Hoping that this was just an unfortunate rare occurrence, I re-typed the entire 473-line program from notes I had kept. When I tried to XEQute it again to resume where I had left off, it worked partially (just as before) and then, at exactly the same place in the data entry, exactly the same problem happened again. I'm therefore faced with having to type it all in yet again (that is, AT LEAST one more time, and probably more than one). Naturally, I'll try stepping through it next time, but when it crashes again, I will again be back to zero. This is very exasperating and time-wasting. It is also extremely discouraging. I had planned to build up gradually (and post to an HP calculators users' forum site) a library of most-useful structural engineering code that would just lie in memory, preserved by always having a spare battery pair and replacing batteries carefully. This unrecoverable crash means I can expect to lose the lot. And that is a big big disincentive to software development on a calculator I can't trust, that has no possibility for external filesaves. I have posted a request for help on the excellent calculator users forum at www.hpmuseum.org . I have asked, 1) Has anyone else had any similar experience? 2) Does anyone have any ideas of what type of code might cause it, so that I can search through my code to try to find MY bug? 3) Has anyone any ideas about how to force a non-destructive reset when the instructions in the manual dont succeed? Be in no doubt, if this problem persists and we can't find out why, then the HP35S, which is otherwise a superb calculator, becomes totally crippled for all serious users. One cannot write serious programs on a calculator with no save facility if it suffers from occasional crashes that wipe the entire library of all programming ever done on it. I have sent a detailed description of this problem to the calculators section of http://wwemail.support.hp.com and my report has been acknowledged by an autogen email from HP Calculator E-mail Support <calculator_support_en@mail.support.hp.com> with reference number KMM20282596V46293L0KM.
I don't know if you will be interested to see the 473-line code that caused this, but I am attaching details in a PC Micro$oft Word file, just in case you would like to see it. Probably-suitable date with which to test it are:
M=100,000,000 Please note that the above program is still only in its final testing/debugging stage. The problem is not that the program doesn't work. Its that it kills the calculator so totally that I hae had to wipe out all programs in it with a hardware reset.
I hope you can help.
Re: Unrecoverable crash to lock-up - Katie Wasserman - 10-02-2007 John, I'd like to see your code that caused this problem, I'm sure that others here would like too as well, maybe you can just post it instead of dealing with separate emails. Are you using vectors in the program? They seem particularly buggy and I've had lots of problems with them particularly in conjunction with "memory full" error messages.
-Katie
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-02-2007 As requested by Katie Wasserman, here's the program. Please bear in mind it was still in final testing stages. The problem for us to resolve, remember, is not how to make my program work (it was very close to being all finished, debugged and tested). The problem here, though, is to discover why the HP35s filled up suddenly with liquid nitrogen, and how to defrost it if it happens again without having to poke it in the warm-me-up-hole in the back, which consigns its contents to oblivion. I've tried in haste to make the listing readable using limited character set available in this forum web editor. If anyone wants the M$Word version (more readable, more reliable) just email me at John@Wasilewski.co.uk (shock horror, a real email address!).
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-02-2007 On 02/10/2007, HP Calculator E-mail Support <calculator_support_en@mail.support.hp.com> wrote: Re: Unrecoverable crash to lock-up - Meenzer - 10-03-2007 Just to clarify before I (maybe) start keying this in my HP 35s: line 357 is supposed to mean "R down"?
I think I will SF/CF flag 10 before and after each text message, just to make sure...
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-03-2007
Re: Unrecoverable crash to lock-up - Meenzer - 10-04-2007 I'm still considering keying that stuff in - but to be honest, the chances are very weak ;-)
And to be frank: as the program uses no rocket science functionality, I'd grab the cheapest calculator I have on my shelf that I can connect to the PC (i.e. the Casio CFX-9850GB+) and do it on that one, while having the convenience to type it on the PC keyboard and running it on an emulator first. You could even have 7-line-menues and coloured graphs for the result ;-) Re: Unrecoverable crash to lock-up - Antoine M. Couëtte - 10-04-2007 Oct 04 th, 2007 Dear John and Meenzer,
So in order to help, I am just offering the following comments with the - hopefully right - assumption that HP35s language is pretty similar to HP 41 language as detailed here under. If such is not the case, then all the following lines are irrelevant, and I do apologize for bringing up some " unwanted noise " to this high quality Forum. Most the following comments are plain good sense, and I certainly would not like to offend both of you through these " over simplistic " or underlined comments. In my own experience, even after many, very many ... HP41 programming hours/days/weeks and months … ( far too many in my Wife’s opinion and judgement … ) I still occasionnaly get caught short and keep stumbling on " easy to avoid " traps. The only advantage experience has brought to me here is that I generally can debug my own programs much faster than in ealier times because I have acquired some kind of a " feeling " about the potential areas where my own programming instructions might eventually go wrong … Through reading your last detailed comments on your program, John, I am just wondering whether your various computation loops are correctly labelled and also whether they do not exceed the maximum authorized " depth level " ( if any applicable on the HP35s ). I am not familiar with HP35s programming, still HP35s language at a first glance seems to be rather similar to a combination of HP41 and HP25 languages with line adressing ( like in the HP25 C ) rather than label adressing ( like in the HP 41 ). This line adressing feature does save programming space, but it forces one to very/extremely carefully keep track of line numbers. Since any time you add or remove one instruction, all subsequent instructions are " line renumbered " and therefore have a different line address, it in turn implies to modify all subsequent/relevant line number references into your XEQ’s and GTO’s instructions. So, before any more in depth crosschecking - and by comparison with HP 41 and HP 25 C programming practices - I would check : - that all GTO’s and XEQ’s instructions refer to correctly numbered ( or correctly " newly/recently renumbered " ) lines, - that all GTO’s and XEQ’s instructions finish up where they are supposed to. My guess is that if they are similar to the HP 41 loops adressing system, all " XEQ " instructions will finish at the first " RTN " or " END " instruction and then resume to the line immediately after the initial " XEQ " , while all " GTO " instructions are simply " plain branching/jumping instructions " just going from one point to another in the programm. So it is extremely important to realize that an " XEQ " instruction cannot be inadvertently replaced by a " GTO " instruction, since, among unwanted results, it WILL ( sorry to write loud ... ) have an ( again most ) undesirable effect on loop(s) depth. - and most importantly, that the " loop depth " does not exceed the authorized " depth level " in the HP 35s. Loop depth on HP41 is a maximum of 6 pending returns if you want to finally exit all loops where you started them. What is " loop depth " on the HP45s ??? Again, I certainly do not want to offend both of you through my " over simplistic and dumb " thoughts. All these comments just to help, unfortunately and maybe not very much of an immediate help since the cross checking path I am suggesting requires a lot of extremely careful understanding /checking /testing about what is going on. Since at a first glance, your Program seems quite " compact and condensed " - which is a very beautiful feature John - maybe it is worth verifying all the hereabove. Another way to look at it is realizing that " nothing is more stupid that a Computer or a Calculator " but once you " cornered it " into doing exactly what you want it to do, then nothing is more " computation/numbers crunching efficient " . Hope it does help …
PS : BTW, I am no longer flying the good old Cargo DC10-30 Aircraft, but just transitioned to the B 757/767 flying again passengers now. Love flying, more than ever …
For HrastProgrammer, on last Friday early afternoon, I flew just a few miles north of Zagreb, and had - again - a quite thankful thought about you and about your wonderful HP 41 Emulator for the HP 48/49/50…. Thank you again here !
Re: Unrecoverable crash to lock-up - Meenzer - 10-04-2007 Puhh, I just keyed in the first 200 lines and am sorry to say: I've had it. No more. Basta! I really give up. If maybe one day there will be a beaming device to transfer code to the HP 35s, I might start anew ;-)
Re: Unrecoverable crash to lock-up - Katie Wasserman - 10-04-2007 John, I think that I understand the mnemonics of all the lines in the program except number 264.
263. RCL O Is the "STO O" supposed to be a PSE? -Katie
Re: Unrecoverable crash to lock-up - HrastProgrammer - 10-04-2007 Why didn't you land? :-)
Re: Unrecoverable crash to lock-up - Thor Lansen - 10-04-2007 My question is, in those many hours of programming have you had a complete crash of your HP41 (as apparently happened with the HP35s)? I do not own and I have no desire for a HP35s, but I own a HP41CX and a HP25C and I had programmed them a great deal (not anymore) and to my recollection (even stuck in infinite loops) I have never experienced something like John mentions. I can relate the problem he described to the annoying blue screens I get with "el crapo" OS that came with my PC (fortunately I have a hard drive to save my work to). It seems to me this is totally unacceptable and even more HP's response (or lack of) to the problem.
Regards, Thor
Re: Unrecoverable crash to lock-up - Arne Halvorsen (Norway) - 10-04-2007 Kind of my thoughts to! While I havent had a serious problem as the one described in this thread I have spent more time that I would like knowing getting out of the 'vector syntax bug state' doing this project Remember having no such problems with my old 41! Note to self: Get my act together and ship the good old one to fixthatcalc!
To bad hp rushed the 35s to the marked :-(
Re: Unrecoverable crash to lock-up - bill platt - 10-04-2007 Hi John, You wrote an impressive program, beautifully arranged, but I have to ask the question: why bother? I can't stand putting more than a few lines together on a calculator; I'd rather do that sort of thing on a proper computer. Nowadays, the only thing going for calculators is, well, calculating.
I am curious: you have a specific reason for putting that kind of program on a calculator?
Re: Unrecoverable crash to lock-up - Antoine M. Couëtte - 10-04-2007 You are very right, Thor : through using standard/conventional programming techniques never either did I experience one single serious HP41 crash similar to the one John described. Still, it came to my mind to carefully check his HP35s program " loop structure " because line addressing is in essence certainly more delicate than using local or global labels. And John made a frequent use of the GTO and XEQ instructions. In this current Program case, if one were absolutely sure that the entire " loop syntax " is fully respected and correct, then we would have a better documented case about a potentially quite serious Machine bug, even more crucial since apparently the HP35s seems to lack ( of ?) any convenient data saving tool. From recent posts, and in particular for the one related to " vector syntax ", the HP 35s seems somewhat deficient, either because it might lack comprehensive and accurate documentation, or simply because it was not extensively tested prior to Market Introduction. And as earlier stated, so long as my guesses about the HP35s programming techniques are valid, I am certainly not pretending to deliver a full and definite answer or explanation to John's serious problems, but just and only giving indications of an area probably worth exploring.
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-04-2007 STO O means Store to register 'O'
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-04-2007 Programs like this get built gradually in spare moments, on train journeys. One starts with a short bit of code that performs some useful function, and works. Then add a little more functionality. And again. It grows. Re: Unrecoverable crash to lock-up - John Wasilewski - 10-04-2007
It was very kind of you to take time to prepare such a good list of tips and I am not in the least offended. They look really interesting and I will study them. I'm sure I won't have thought of all of them. Re: Unrecoverable crash to lock-up - John Wasilewski - 10-04-2007
Katie, what's your email address? Re: Unrecoverable crash to lock-up - John Wasilewski - 10-04-2007 But I actually WANT to do it on an HP35s. Re: Unrecoverable crash to lock-up - John Wasilewski - 10-04-2007 Good chance that loop structure is why the program fails. Re: Unrecoverable crash to lock-up - Meenzer - 10-04-2007 Quote:
;-) For 1, 2a, 2b, and 4 you could use the HP 48G AND have the link option. I concede it's no good for impressing anyone ;-)
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-04-2007
Sorry Katie, I explained 263, so I replied to the wrong question. Re: Unrecoverable crash to lock-up - bill platt - 10-04-2007 I appreciate the train journey aspect, being a train buff myself. For me, I/O becomes important for larger programs, libraries etc. It seems to me that the 50G makes a lot more sense (or for retro a 48GX). You can run an emulator on it for the 41cx, and therefore you can develop in RPN rather than RPL if it suits you. And you have backup, and I/O. Best regards,
Bill
Re: Unrecoverable crash to lock-up - Katie Wasserman - 10-04-2007 Thanks for the explanation.
I've been playing with parts of your program trying to recreate the lock-up bug with no luck so far.
Re: Unrecoverable crash to lock-up - DaveJ - 10-04-2007 Quote: That is precisely why I don't understand the reasoning behind the new 35S. Fair enough having programming capability on a non-I/O calculator, it's very useful, but why optimise the keypad layout for programming at the expense of ease of regular calculations? They changed this from the 33S to the 35S, why?
Dave.
Re: Unrecoverable crash to lock-up - John Limpert - 10-10-2007 I typed in your program, although I won't guarantee that I didn't make any errors. My aging eyes have a hard time distinguishing between the symbols used for addition and division. It seemed to run OK, and it did not lockup or crash.
John Wasilewski ... here's what I suggest... - Gene Wright - 10-10-2007 I'm not sure what country you are in, but I think you have a valid reason to return the unit for an exchange. It seems that you have a machine with a problem that no one else is experiencing. Perhaps that is a result of a bad batch. More likely there is just something wrong with the innards of your machine. Despite Katie's frustrations :-) many of us are using the 35s and taxing the unit in many ways without ever seeing any crashes or behavior that gives us problems the way you are seeing them. So, call HP's phone number, patiently explain that your HP 35s is not operating properly. I would not say that you are programming the machine, etc, as that would confuse the issue with whoever answers the phone. I would say that it locks up and does not function correctly, that you cannot reset the machine using the steps described in the manual without using the reset pin on the back which causes you to lose your data. Explain how your friends with a 35s are not experiencing this type of problem and that you want to exchange your unit for another one that should not have this problem. Do remember that the person on the phone talking to you from HP is part of the entire HP corporate world and will probably know little to nothing about HP calculators. Let us know what the response is. If they are not helpful, let me know. A 35s should not behave like this and yours should be exchanged. ok? :-)
Gene
Re: Unrecoverable crash to lock-up - John Wasilewski - 10-11-2007 Reply to John Limpert. Thank you for taking so much trouble to help with this problem. Did you over-ride the prompt-suggested depth and width sizes with smaller values as input? THis is necessary to force the program to calculate compression steel. When the program reaches line 264 it issues an alpha prompt for comp and tension steel then stops to wait for input (this is the action obtained when no PSE statement follows an alpha string whilst flag 10 is set). id you then enter just a tension steel diameter and press R/S (eg 20 R/S)? It is only after the above steps have been passed that the endless loop is reached which I can't break out of.
---
(ps sent from an Internet cafe)
|