Announcement

Collapse
No announcement yet.

Error at "compact"

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error at "compact"

    Please let me know the meaning of these errors...

    1. "1153 pNextBlock is not valid: 0x00000000"
    2. "441 Not in heap"

    This error messages are appeared at the log

    > enable
    (enable)#device
    (device)#show tlog

    And when do these errors are appeared? What is problem?

    Best regards,
    Yuichi IDE

  • #2
    Error messages

    1) pNextBlock is not valid
    This happens if the Flash file system is corrupted, perhaps due to powering off or stopping the code before a file write operation has completed. You can recover via the "format" or Device installer Serial Recovery with the erase all Flash box checked; both operations will wipe out anything on the file system.

    2) Not in heap
    This happens when Free(p) is called, but p is not in the heap. The most common coding mistake that results in this error is to call Free(p) more than once.

    Comment


    • #3
      What is changed between 3.0.0.1R8 and 3.2.0.1R11?

      Thanks for you reply, scook!

      Please let me know what is changed between 3.0.0.1R8 and 3.2.0.1R11.
      Because these errors have never happened at SDK 3.0.0.1R8.

      So, we have to know and inform TWO POINTS!

      1) What is changed, as detail as possible
      2) What we have to change

      Please help me ...

      Comment


      • #4
        Differences and what to do

        1) The newer version of code is larger. It requires more of the Flash and leaves less for the file system. This means that the file system is relocated. You can recover via the "format" or Device installer Serial Recovery with the erase all Flash box checked; both operations will wipe out anything on the file system.

        2) The newer version adds more run time error checking, so it provides the "Not in heap" message. It is quite possible that your code had a memory error all along, but only now are you seeing this complaint. We use a breakpoint at the message so we can see what causes the problem.
        For example:
        void *p = MALLOC(100); /* This gets memory from the heap. */
        Free(p); /* This returns memory to the heap. */
        Free(p); /* This causes the error, because it is already freed! */

        Comment


        • #5
          A file is disappeared...

          We checked the log of our application. We can find that "file open" is failed just before "compact" start and the file is disappeared after "compact" finishes. So, we concern that the "file entry" is destroyed because of the failure of "file open" or "compact" processing.

          About the threshold to which SDK executes compact...

          1) When does the SDK execute "compact" ? How many is the value of "Clean Space" at that time ?
          Does "compact" start when the size of argument of "fwrite" become larger than that of "Clean Space"?
          2) When does the SDK judge whether "compact" is executed ?

          Other Question
          A) Why does "NULL" return when a new file is made by "fopen"?

          Anyway, These strange phenomenon is not happened at 3.0.0.1R8. Please help us...

          Best regards,
          Yuichi IDE

          Comment


          • #6
            Compact

            1) The file system never performs a Compact until is absolutely needs to. Notice that the file system statistics show you "clean space" and "dirty space". Clean space is available for writing file data. Dirty space is not available for writing file data until after a Compact. When a file is erased, its contents become part of the dirty space. When the file system attempts to write but the clean space is less than a header (about 16 bytes), it will perform Compact to free up the dirty space.
            2) The only other way to Compact is by user request via the web or CLI command.
            3) If, after Compact, there STILL is no room for the write, it will fail.
            4) If there is no room, an fopen will return NULL.
            5) Also fopen will return NULL if the file path/name is too long.

            Okay, that answers your new questions. But your problem still sounds to me like one of the following:
            1) You may have a corrupted file system. You must format to recover. Have you done this yet?
            2) Be aware that your file system space is SMALLER now because the new version of firmware is LARGER. You may simply have run out of space.

            Comment


            • #7
              About the following...

              1) You may have a corrupted file system. You must format to recover. Have you done this yet?

              Yes, we have already done.

              2) Be aware that your file system space is SMALLER now because the new version of firmware is LARGER. You may simply have run out of space.

              We keep 1MByte space for file system.
              The detailed information of file system is the following:

              (filesystem)#s
              Filesystem Statistics:
              Filesystem size : 1024.000 Kbytes (1048576 bytes)
              Available space : 158.806 Kbytes (162618 bytes) (15%)
              Clean space : 114.944 Kbytes (117703 bytes) (11%)
              Dirty space : 43.862 Kbytes (44915 bytes) (4%)
              File & Dir space used : 865.193 Kbytes (885958 bytes) (84%)
              Data space used : 845.393 Kbytes (865683 bytes)
              Number of files : 424
              Number of directories : 12
              Number of system files : 2
              Opened files : 0
              Locked files : 0
              Opened for sharing : 0
              Current directory : /
              Current Bank : B
              FW sectors : 00 - 31, 0 erase cycles
              Bank A sectors : 32 - 47, 82 erase cycles
              Bank B sectors : 48 - 63, 82 erase cycles
              Busy : No

              And ROM size of firmware is 1,953,792 Byte.
              The size of file which is written is 5 - 6,408 Byte.

              The other question...
              Why is the return value of "fclose" ALWAYS "-1" when "r" is selected at the mode of "fopen"? But when "w" is selected, the return value of "fclose" is always "0".

              Best regards,
              Yuichi IDE

              Comment


              • #8
                fclose

                Regarding fclose, thank you, this is a good catch.

                When the file was open just for reading, there is actually no possibility of an error return from fclose, and it should have returned 0.

                When the file was open for writing, there really is a possibility of error in the case that fclose causes the last bytes to be written and the write could possibly fail.

                Comment


                • #9
                  Your filesystem statistics

                  Your filesystem statistics look fine. You have enough space for your new file.

                  So, at this point, I seem to have no more clues about your problem. If I were at your side sleuthing this, my approach would be to carefully discover how to repeat the problem then to carefully minimize the steps and /or amount of custom code involved. The objective is to discover a simple repeatable scenario to demonstrate some problem. If we can reproduce a problem here, we are confident that we can fix it.

                  Comment


                  • #10
                    Originally posted by scook View Post
                    Regarding fclose, thank you, this is a good catch.

                    >When the file was open just for reading, there is actually no possibility of an error return from fclose, and it should have returned 0.

                    When the file was open for writing, there really is a possibility of error in the case that fclose causes the last bytes to be written and the write could possibly fail.
                    I think that You are misunderstanding...

                    When "r" is set to "fopen", "fclose" always return "-1".
                    When "w" is set to "fopen", "fclose" always return "0".

                    Why? please let me know...

                    Best regards,

                    Comment


                    • #11
                      Originally posted by scook View Post
                      Your filesystem statistics look fine. You have enough space for your new file.

                      So, at this point, I seem to have no more clues about your problem. If I were at your side sleuthing this, my approach would be to carefully discover how to repeat the problem then to carefully minimize the steps and /or amount of custom code involved. The objective is to discover a simple repeatable scenario to demonstrate some problem. If we can reproduce a problem here, we are confident that we can fix it.
                      Thanks.
                      By the way, I have 1 request and 1 question.

                      Request.1 : Could you give the file "fastfile.c"?

                      Question.1 : If we send the firmware including the user application, could you sleuth the problem?

                      Best regards,

                      Comment


                      • #12
                        Additional question!

                        When the "Compact" is processing, are the other processes like serial communication, file access or Ethernet communication... stopped by SDK?

                        Best regards,
                        Yuichi IDE

                        Comment


                        • #13
                          fopen

                          Yes, I understood. Please forgive me for being so confusing!

                          >When "r" is set to "fopen", "fclose" always return "-1".

                          Yes. This is true. Technically, it is a mistake. Yesterday I fixed it for future releases (so it will return 0). However, it is not a serious problem for you because there is actually no possible failure case in this scenario, so you do not need to test the return code.

                          >When "w" is set to "fopen", "fclose" always return "0".

                          No, this is false. There is a possibility that some data that you have previously written to the file has not yet been flushed into Flash. If this is the case, it is the job of fclose to write that remaining data. If that write were to fail because the file system is full, it would return a negative code.

                          Comment


                          • #14
                            Compact

                            While a compact is being performed, it holds a semaphore that is required for exclusive access to the file system.

                            If an independent task attempts to read or write during this time, it will be blocked on that semaphore until the compact operation is complete. If an independent task had a file open for write and had performed some writes BEFORE the compact began, it would also be blocked until the compact operation completes, then afterward it would be allowed to continute to perform writes.

                            If a task performs serial and Ethernet communication WITHOUT PERFORMING EVEN A SINGLE FILE OPERATION, it would continue to run as usual even while a compact operation is in progress.

                            Please be aware that the web manager reads the file system frequently. All of its HTML and JavaScript reside on the file system.

                            Comment


                            • #15
                              Same problem !

                              Hi IDEYuichi,

                              Have you solved your problem ? I also have files that disappear.

                              I have four directories : tree with html pages and one with data files.
                              I record datas only in the data directory.
                              Sometimes, two of the tree directories with my html files are empty and I lose my web interface. On the other side, I do not lose files on the datas directory.

                              an idea ? Thank you for your help...

                              Pascal

                              Comment

                              Working...
                              X