Loading ...
Sorry, an error occurred while loading the content.
 

more Fatal Alerts since last pToolSet update

Expand Messages
  • Bill Starr
    I have noticed that I seem to be getting more Fatal Alerts since I installed pToolSet 6.63 (13 July 2003). The two I see most frequently are: MemoryMgr.c,
    Message 1 of 11 , Jul 31, 2003
      I have noticed that I seem to be getting more Fatal Alerts since I
      installed pToolSet 6.63 (13 July 2003). The two I see most
      frequently are:

      MemoryMgr.c, Line: 4450, Invalid chunk ptr
      NotifyMgr.c, Line: 2269, Stack overflow

      The typical scenario for me is:

      - press "123" to activate pMasterTool
      - open pMagiPad
      - type text string (within Palm Find length constraint)
      - use button bar "S" to select all current text and copy to clipboard
      - "OK" to exit magiPad
      - click "Find" icon to activate pFindTool
      - "123" to open pMasterTool over pFindTool
      - "paste text" to pFindTool using pMasterTool menu
      - Fatal Alert pops up

      This one is pretty repeatable, even after a soft reset. If it does
      not happen the first time, it will often occur on the second or
      third try. It appears to occur most often when initiating the search
      from within DateBk4.

      Sometimes I get the MemoryMgr and sometimes the NotifyMgr message.

      I realize there a number of possible interactions going on, but I
      definitely started seeing these more often after this last update.
      Of course, I had not had the "paste" option in pMasterTool up until
      that point either, I don't think.

      Anybody else noticing this, or can duplicate it?
    • Paul Nevai
      HI Bill: # I have noticed that I seem to be getting more Fatal Alerts since I # installed pToolSet 6.63 (13 July 2003). The two I see most # frequently are: #
      Message 2 of 11 , Aug 1, 2003
        HI Bill:

        # I have noticed that I seem to be getting more Fatal Alerts since I
        # installed pToolSet 6.63 (13 July 2003). The two I see most
        # frequently are:
        #
        # MemoryMgr.c, Line: 4450, Invalid chunk ptr
        # NotifyMgr.c, Line: 2269, Stack overflow

        # This one is pretty repeatable, even after a soft reset. If it does
        # not happen the first time, it will often occur on the second or
        # third try. It appears to occur most often when initiating the search
        # from within DateBk4.

        #1. What OS?

        #2. I talk a lot about stacks in pedit's manual. Read about it and then fix
        it using the advice there. Search for the word "stack".The reason is that
        DateBk4 does not create a stack recommended by "modern" apps. This way it is
        compatible,with OS 1.0 and such. See also MemBrain.

        pedit even includes a stack increaser function but it does it for pedit only.

        Interestingly, I never saw a "NotifyMgr.c, Line: 2269, Stack overflow"
        myself.

        BTW, what are you doing with DateBk4 when there is DateBk5?

        Best regards, Paul
      • Paul Nevai
        # - press 123 to activate pMasterTool # - open pMagiPad # - type text string (within Palm Find length constraint) # - use button bar S to select all
        Message 3 of 11 , Aug 1, 2003
          # - press "123" to activate pMasterTool
          # - open pMagiPad
          # - type text string (within Palm Find length constraint)
          # - use button bar "S" to select all current text and copy to clipboard
          # - "OK" to exit magiPad
          # - click "Find" icon to activate pFindTool
          # - "123" to open pMasterTool over pFindTool
          # - "paste text" to pFindTool using pMasterTool menu

          BTW, this is the wrong way to do it. You could ccopy'n'paste directly from
          pMagiPad into pFindTool. BUT this is not a crash preventer. Just more
          efficient.

          click "Find" icon to activate pFindTool
          open pMagiPad
          type
          copy'n'paste [see the Edit menu]

          Best regards, Paul
        • W. B. Maguire II
          Paul: ... May I answer that for *myself*? ... I use an app. to manage the color scheme on my Visor Prism. Why? Because I *much* prefer to read and edit light
          Message 4 of 11 , Aug 1, 2003
            Paul:

            At 05:21 AM 8/1/03 -0400, you wrote:
            > :
            > :
            >BTW, what are you doing with DateBk4 when there is DateBk5?


            May I answer that for *myself*?

            -----BACKGROUND:-----

            I use an app. to manage the color scheme on my Visor Prism. Why? Because
            I *much* prefer to read and edit light text on a dark background (a sure
            sign of an old-time programmer! ;-) ), rather than the PalmOS default of
            black-on-white. In order to accomplish this personalization, I use a
            PalmOS application called "Butterfly" (highly recommended) (and "Khroma"
            before that, and "Chrome" before that,...). Butterfly is a very well-done
            program that allows me to change the color of 22 different components of
            the PalmOS, e.g. "Form Frame/Fill", "Dialog Frame/Fill", "Alert
            Frame/Fill", "Menu
            Frame/Fill/Foreground/Selected-Fill/Selected-Foreground", "Control
            Frame/Fill/Foreground/Selected-Fill/Selected-Foreground", and "Field
            Background/Text/Text-Lines/Caret/Text-Highlight-Background/Text-Highlight-Foreground".
            For instance---rather than removing them completely---I can change those
            annoying text-field dotted-lines into a nice blue on my black text-field
            background (still there but subtly in the background).

            Butterfly performs *flawlessly* with all applications that "play by the
            rules" when it comes to elements of their forms and coloring of such---like
            pedit and *every* other application on my Prism. Unfortunately, the DateBk
            author flushes the rules, as I'll discuss below.

            -----DATEBK ISSUE:-----

            Unfortunately, the guy who writes DateBk (CESD / Pimlico Software) knows
            better than *every* consumer, and decided that he must *force*
            (INCONSISTENTLY) the colorization of his application, rather than let the
            OS control it. In DateBk4 there were some problems, but I am able to live
            with them. For instance, I can't let DateBk4 control the alarms, because
            when the alarm screen shows, DateBk4 *forces* the background of the
            alarm-description text to be white (rather than using an OS-defined color
            like the "Text Background"), but did *not* force the foreground text to be
            black (he *did* use the OS color---"Text Foreground"---here). My
            colorization software---Khroma at the time---couldn't do anything about the
            forced-white background, but it *did* change the foreground text to
            white. The result: white text on a white background; real
            informative! >:-P Luckily, I'm able to *usually* get past this through
            the DateBk4 option of letting the built-in DateBook control the alarms
            (although that is a pain---in itself---for various reasons stated in the
            manual). Another similar---but less critical---example is the month view;
            DateBk4 *forces* the lines that make-up the calendar to be black (rather
            than choosing a more *intelligent*---not hard-coded---color! Like maybe
            the OS's foreground-text color?), but the background is the "Form Fill" (I
            believe) color which I have set to a dark navy blue (of course, this
            normally works great when all the foreground text/lines/etc. are a *light*
            color). The result: black lines on a dark navy-blue background. Not too
            clear. There are additional examples, but, like I said, I learned to live
            with these problems.

            Before resigning to just *living* with these problems, though, I contacted
            the author of DateBk4. In a sincerely *helpful* tone, I went into great
            detail (like this letter) about why *forcing* some colors to hard-coded
            values---rather than using one of the OS-determined palette values (that
            Butterfly could then change)---was a real problem for people with color
            devices who wanted to *customize* the interface of those devices. I
            mentioned that customization was probably a small audience now, but was
            *definitely* the way of the future! Just look at all those applications
            out there that have the (frequently useless) ability to change
            "skins". For God's sake, they're even starting to do it *electronically*
            for cell phone exteriors! I told him that Khroma (what I used at the time)
            was an *excellent* piece of freeware, and that this problem would just bite
            more and more Khroma+DateBk users in the future.

            This is---in its entirety---his response (of 31-Jan-2002):

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            >IT is neither practical nor feasible for me to modify my program to
            >accomodate [sic] personal choices that you make for color schemes based
            >on some other third party program that is twiddling the system palette
            >underneath DateBK4.
            >
            >That may be subject to review at some later time, but it won't be made in
            >the forthcoming V-4.1/5.0. I will put it on the list of things to review in
            >the future.
            >
            >Cheers!
            >CESD, Pimlico Software, Inc.
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            He obviously didn't really *read* my letter, because I clearly stated that
            we were not talking about unpractically catering to a tiny hacker audience,
            but rather---as Paul often puts it---PLAYING BY THE RULES. When a software
            author *plays by the rules*, it provides more flexibility for *other*
            software that may build upon the original author's product. Using DateBk's
            author's (il)logic, there is no need for a color palette at all! Palm
            should have asked *Pimlico* what 8 colors *they* wanted everyone to have
            (why bother with 65536 colors?), the PalmOS could support those 8 colors,
            and every application could hard-code the colors for every element of its
            interface. No worries about pesky personal choices, right? Oh wait, there
            *is* a reason that computers use a *palette* of colors, and programs then
            *reference* that palette, because that way is the *smart* way, not the
            *stupid* way!

            LapTopHack is an *exact* analogy for this issue! Any Palm app. that uses
            its own, custom, non-standard interface will *not* be able to be controlled
            by LTH. So, a short-sighted (polite for "nimrod") software author will
            make his fancy, pretty, non-standard picture-buttons to be tapped by a
            stylus, without the slightest inkling that this will render his product
            almost totally useless in a *keyboard* environment. Since that software
            doesn't play by the rules, LTH is prevented from working its
            brilliance! The DateBk products do *not* play by the rules, and they've
            become *worse* with each new version. As long as you prefer *all* of the
            pre-chosen colors of the DateBk interface, you're fine. If you get excited
            over a product like Khroma or Butterfly, thinking "Wow! I can make all the
            colors in my Palm applications be the way *I* want them! I can have
            off-white text on a dark-navy-blue background instead of black on white!",
            you'll be *very* disappointed to find out that DateBk ignores some of your
            choices---but not others---leading to a disastrous mess of colors and a
            totally illegible result.

            When I downloaded DateBk5 (for a trial before purchasing), everything
            looked *awful*! Pimlico forces the colors---inconsistently---on even
            *more* of the critical form elements in DateBk5 than in
            DateBk4! Really! The day-view (the most important for me!) was
            *completely* illegible! Random colors everywhere! Needless to say, I
            quickly reverted back to the only-semi-busted DateBk4. And that's the
            long-winded explanation for why *I* am forced to stick with the older DateBk4.

            Lastly, I have to say that with the advent of the Butterfly program, this
            color problem can be somewhat alleviated---although not to *my*
            liking. The author of Butterfly---wisely---saw that there was a very small
            population of programs/programmers that are viciously opposed to
            standardized color-palette use, and so he added the capability to turn
            *off* the palette manipulation for those 'nimrod' applications (that you
            choose from a list of all the programs on your Palm). This feature would
            allow me to use DateBk4 or DateBk5 using the *standard* Palm colors and the
            *specific* black-, red-, and blue-on-white colors that the DateBk author
            decreed for everyone. But I *hate* looking at that black (and blue and
            red) text on a bright white background; therefore I live with my color
            scheme and the less-busted DateBk4 over the completely-busted DateBk5. So,
            there *is* a solution with Butterfly, it's just not the *best*
            solution. The *best* solution is for DateBk's author to *use* the
            *feature* that is the OS color palette for form elements ... to *allow* you
            the freedom to customize your color palette ... to PLAY BY THE RULES!

            Bruce.

            --
            Yahoo-ized (stupid "`" place-keepers required) and
            Spam-resistant (replace "_at_" with "@") signature:

            ` _________ Maguire_at_AnalyticInvestments.com _____ |**===
            `/ ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` |**===
            (` W. B. Maguire II, Ph.D. `` Tel: 303.772.1615 `` ` |=====
            |` Chief Executive Manager `` FAX: 303.651.6389 `` 9||
            |` Analytic Investments LLC ` ` ` ` `_` ` ` ` ` ` ` ` ` ` |
            |` 700 Ken Pratt Blvd STE204 PMB166 ( ) The ASCII ribbon `|
            (` Longmont CO, 80501-6455 ` ` ` ` ` X ` campaign against )
            `\_________________________________ / \ _ HTML e-mail ___/
          • Bill Starr
            Thanks for your reply, Paul. 1) I have a Palm Vx with OS 3.5.3. 2) I m hoping that DateBk5 does not have this issue with the stack. 3) Until today, I had
            Message 5 of 11 , Aug 1, 2003
              Thanks for your reply, Paul.

              1) I have a Palm Vx with OS 3.5.3.

              2) I'm hoping that DateBk5 does not have this issue with the stack.

              3) Until today, I had resisted upgrading from the last version of
              DateBk4 due to the memory hit. I have been happy with the
              capabilitities, and only have about 10 percent of my 8M RAM free, so
              had wanted to avoid losing about 1/4 of my free space by upgrading.

              Today I bit the bullet and deleted some large app's and DOC files I
              rarely use. Then I updated to the last DateBk5 release. Even after
              the update, I now have about 13 percent free. So far no Fatal Alerts
              since updating, even when running through the typical scenario I had
              outlined.

              Regards, Bill


              *****
              Message 22238
              From: Paul Nevai <nevai@m...>
              Date: Fri Aug 1, 2003 4:21 am
              Subject: Re: [peditors] more Fatal Alerts since last pToolSet update

              #1. What OS?

              #2. I talk a lot about stacks in pedit's manual. Read about it and
              then fix it using the advice there. Search for the word "stack".The
              reason is that DateBk4 does not create a stack recommended
              by "modern" apps. This way it is compatible,with OS 1.0 and such.
              See also MemBrain.

              3) BTW, what are you doing with DateBk4 when there is DateBk5?


              *****
              Message 22237
              From: "Bill Starr" <bill.starr.yahoo@s...>
              Date: Thu Jul 31, 2003 9:17 pm
              Subject: more Fatal Alerts since last pToolSet update

              I have noticed that I seem to be getting more Fatal Alerts since I
              installed pToolSet 6.63 (13 July 2003). The two I see most
              frequently are:

              MemoryMgr.c, Line: 4450, Invalid chunk ptr
              NotifyMgr.c, Line: 2269, Stack overflow

              This one is pretty repeatable, even after a soft reset. If it does
              not happen the first time, it will often occur on the second or
              third try. It appears to occur most often when initiating the search
              from within DateBk4.
            • Paul Nevai
              # Today I bit the bullet and deleted some large app s and DOC files I # rarely use. Then I updated to the last DateBk5 release. Even after # the update, I now
              Message 6 of 11 , Aug 1, 2003
                # Today I bit the bullet and deleted some large app's and DOC files I
                # rarely use. Then I updated to the last DateBk5 release. Even after
                # the update, I now have about 13 percent free. So far no Fatal Alerts
                # since updating, even when running through the typical scenario I had
                # outlined.

                Actually, DateBk5 did not solve the stack problem. I never ever had problems
                with it though. I use it too. Take a look at TealMemBrain. Or fix the stack
                of DateBk5. It is easy to do with RsrcEdit. Copy pedit's stack pref resource
                to DateBk5. Look in the manual for "'pref' #0" resource.

                Best regards, Paul
              • Bill Starr
                I m not sure what you mean by wrong , unless you mean less- efficient. I was not aware (or had forgotten) that pMagiPad had this command. Thanks for pointing
                Message 7 of 11 , Aug 1, 2003
                  I'm not sure what you mean by "wrong", unless you mean less-
                  efficient.

                  I was not aware (or had forgotten) that pMagiPad had this command.
                  Thanks for pointing it out. I may try using it more often.

                  I do almost everything by taps, rather than keyboard and / or
                  graffiti. I think what I lose by using three taps to navigate to and
                  select the Copy'N'Paste from the pMagiPad menu I make up for by not
                  having to tap "OK" to exit pMagiPad, then "123" to activate
                  pMasterTool, then one more tap to select Paste from my customized
                  menu.


                  *****
                  Message 22239
                  From: Paul Nevai <nevai@m...>
                  Date: Fri Aug 1, 2003 4:24 am
                  Subject: Re: [peditors] more Fatal Alerts since last pToolSet update

                  # - press "123" to activate pMasterTool
                  # - open pMagiPad
                  # - type text string (within Palm Find length constraint)
                  # - use button bar "S" to select all current text and copy to
                  clipboard
                  # - "OK" to exit magiPad
                  # - click "Find" icon to activate pFindTool
                  # - "123" to open pMasterTool over pFindTool
                  # - "paste text" to pFindTool using pMasterTool menu

                  BTW, this is the wrong way to do it. You could ccopy'n'paste
                  directly from pMagiPad into pFindTool. BUT this is not a crash
                  preventer. Just more efficient.

                  click "Find" icon to activate pFindTool
                  open pMagiPad
                  type copy'n'paste [see the Edit menu]


                  *****
                  Message 22237
                  From: "Bill Starr" <bill.starr.yahoo@s...>
                  Date: Thu Jul 31, 2003 9:17 pm
                  Subject: more Fatal Alerts since last pToolSet update

                  The typical scenario for me is:

                  - press "123" to activate pMasterTool
                  - open pMagiPad
                  - type text string (within Palm Find length constraint)
                  - use button bar "S" to select all current text and copy to clipboard
                  - "OK" to exit magiPad
                  - click "Find" icon to activate pFindTool
                  - "123" to open pMasterTool over pFindTool
                  - "paste text" to pFindTool using pMasterTool menu
                • Paul Nevai
                  # I do almost everything by taps, rather than keyboard and / or # graffiti. I think what I lose by using three taps to navigate to and # select the
                  Message 8 of 11 , Aug 2, 2003
                    # I do almost everything by taps, rather than keyboard and / or
                    # graffiti. I think what I lose by using three taps to navigate to and
                    # select the Copy'N'Paste from the pMagiPad menu I make up for by not

                    No need to navigate to it: command-q or ESC q. Best regards, Paul

                    P.S. Should I assign "copy'n'paste" to a button-slided "P"?
                  • Paul Nevai
                    # I m not sure what you mean by wrong , unless you mean less- efficient. Yep. /Paul
                    Message 9 of 11 , Aug 2, 2003
                      # I'm not sure what you mean by "wrong", unless you mean less- efficient.

                      Yep. /Paul
                    • C. E. Steuart Dewar
                      ... The DateBk calendar program was written a couple of years before color devices appeared and even before hacks appeared. In the earliest versions of the OS,
                      Message 10 of 11 , Aug 2, 2003
                        > Unfortunately, the guy who writes DateBk (CESD / Pimlico Software) knows
                        > better than *every* consumer, and decided that he must *force*
                        > (INCONSISTENTLY) the colorization of his application, rather than let the
                        > OS control it.

                        The DateBk calendar program was written a couple of years before color
                        devices appeared and even before hacks appeared. In the earliest versions of
                        the OS, everything was hard-wired, and so it was not unusual for third party
                        applications to be written on the assumption that things that were
                        hard-wired in the device were not likely to change. Of course, we all made
                        SOME accomodations for potential future changes, but when you originally
                        develop an application that has to run on a device with at best 512k of
                        memory, you have to be very parsimonious in including extra code on the
                        off-chance it might be needed in the future.

                        So this is not a case of intentionally sidestepping the standard color
                        scheme of the Palm OS. It was a matter of not having the available time to
                        spend several days of work sifting through 100,000 lines of code looking for
                        every single case where color is applied and adding the code to pull the
                        default color off the UIcolor table. At that time, I was dealing with core
                        functionality issues that affected ALL users of the application.

                        The Palm OS has the provision for setting the screen size, but if someone
                        wrote a hack to take over the bottom 20 pixels of the screen for a status
                        display and told the third party app the screen was actually 160x140, you
                        can be very sure that few (more likely none) third party applications would
                        be accomodating. Just because the Palm OS has a feature that is unused on a
                        standard device does not mean that every application has to fully implement
                        it on the off-chance that one day someone might write a hack that require
                        all apps to conform to that feature.

                        Everything has to do with priorities and the point was that those few days
                        of effort were far more important to devote to something that many hundreds
                        of thousands of users wanted rather than something that probably only
                        affects a few hundred (at most) users and then only at a cosmetic, not a
                        functional level.

                        I have on every release, caught more and more items. At this point, there
                        are very few (meaning none that have been recently drawn to my attention)
                        places left in the current V-5.1a release that do not conform to the
                        standard color palettes. I made it a higher priority in V-5.1a because of
                        the appearance of themes which depend upon that conformance for a consistent
                        display...

                        The comment that it has gotten worse is uninformed. And I will continue
                        to address any other places that are drawn to my attention.

                        As for the stack issue, I don't recollect what the minimum available stack
                        size was for DateBk4 while it was running, but my guess is that it was at
                        least 1,500 bytes (based on the fact that the larger and more complex
                        Datebk5 never left less than 2k bytes). However, in V-5.1a of DateBk5, I DID
                        increase the stack size by another 1k since there are more and more newer
                        hack writers who tend to lack parsimony in that area and for the end user, a
                        crash is a crash - regardless of how or why it was caused. Hack writers
                        should always use dynamic stack frames so they steal as little stack space
                        as possible from the applications running above (and most of the good hack
                        writers I know have been doing that for some time if they needed a lot of
                        local storage). DateBk4 & DateBk5 have always used dynamic stack frames in
                        all the alarm code for just that reason...

                        Cheers!
                        CESD, Pimlico Software, Inc.
                        ==========================================
                      • Bill Starr
                        That idea sounds wonderful, Paul. I ll be glad to try it out if you like. As I ve mentioned before, I seldom use my PPK since I found FitalyHack. Graffiti is
                        Message 11 of 11 , Aug 2, 2003
                          That idea sounds wonderful, Paul. I'll be glad to try it out if you
                          like.

                          As I've mentioned before, I seldom use my PPK since I found
                          FitalyHack. Graffiti is fine occasionally, and I'm pretty proficient
                          at it, but I have had trouble with something akin to "graffiti
                          degradation" (Ref: following link) for nearly as long as I've had my
                          Palm Vx. I confirmed this with GrafAid. I tried to figure out what
                          causes it, but finally gave up and just found ways to accommodate,
                          including using Fitaly for almost all text entry.

                          http://www.geocities.com/SiliconValley/Campus/9054/tapbuga.html

                          Because of the "spurious straight diagonal lines [which] appear
                          instantaneously at the start of a Graffiti stroke", I can't count on
                          any particular graffiti stroke being accurate. This is merely
                          annoying when trying to produce accurate text. But when trying to
                          execute commands, as with a command stroke, or LTH or pedit or
                          pToolSet escape sequence, it can cause the loss of data, so I try to
                          do as much as I can with taps (or slides), since they are generally
                          more reliable for me.

                          Thanks, Bill


                          *****
                          Message 22248
                          From: Paul Nevai <nevai@m...>
                          Date: Sat Aug 2, 2003 6:19 am
                          Subject: Re: [peditors] Re: more Fatal Alerts since last pToolSet
                          update

                          No need to navigate to it: command-q or ESC q. Best regards, Paul

                          P.S. Should I assign "copy'n'paste" to a button-slided "P"?


                          *****
                          Message 22247
                          From: "Bill Starr" <bill.starr.yahoo@s...>
                          Date: Fri Aug 1, 2003 9:49 pm
                          Subject: Re: more Fatal Alerts since last pToolSet update

                          I do almost everything by taps, rather than keyboard and / or
                          graffiti. I think what I lose by using three taps to navigate to and
                          select the Copy'N'Paste from the pMagiPad menu...
                        Your message has been successfully submitted and would be delivered to recipients shortly.