Announcement

Collapse
No announcement yet.

XPort Pro Evolution SDK 5.4.0.0R7

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

  • XPort Pro Evolution SDK 5.4.0.0R7

    Here's the latest SDK installer for the XPort Pro Evolution.
    Attached Files

  • #2
    Is there a change log?

    Comment


    • #3
      Originally posted by xppusr View Post
      Is there a change log?
      xppusr I found a few points in "xport_pro_5_4_0_2_R1_User_Release_Notes.txt". Some of them (not all) are also in the current file "xport_pro_5_5_0_1R6_User_Release_Notes.txt".

      Another question: Is there a known heap issue in this version (V5.4.0.0 R7)? I have seen three independent devices that have run out of memory. SSH access (to activate the syslog sender) was not possible (maybe because of heap?). But tracing a HTTP request shows the following answer: "HTTP 400" / "Bad Request: Memory Allocation Failed". This error message is generated by EvolutionOS, not by our application. All of the three devices have an uptime of more than 400 days when the problem appeared. Rebooting solved the problem (so far...).

      I looked through our code. There are only few places where malloc is used - but Free() gets always called. So is there a known issue in this version of Evolution OS?

      Comment


      • #4
        Memory fragmentation can be a problem

        Comment


        • #5
          Fragmentation in general, not related to this specific version.

          Comment


          • #6
            Are there any improvements in V5.4.0.2 R5 (against V5.4.0.0 R7) regarding the heap management?

            Is there a possibility of intervention to avoid such a big fragmentation that HTTP server does not work any more?

            Comment


            • #7
              Does this problem exist in the standard firmware or only when you add your code? Can you see in the diagnostics what is happening to the memory?

              Comment


              • #8
                Of course we have our application running there. The Lantronix Frondend does not exist. Telnet is switched off. If the phenomenon occurs, ther is also no access over SSH to the device. All devices have been running for over 400 days, it is difficult to run a test installation at our customer (for this long period).

                Comment


                • #9
                  If you can not get to diags, then consider having TLOG write to the file system. Have your application also write to TLOG occasionally to track the memory. While I'm not a fan of logging to flash, sometimes you have no choice. You'll need access to extract the log file. Best case, have the application track the RAM and reboot if when it gets too fragmented. Assuming that's the problem.

                  Comment


                  • #10
                    Writing TLOG to the file system sounds nearly impossible. The problem occurs after more than one year of uptime...

                    We have four devices for testing - all of them are running without any problem (but less than 400 days). "Unfortunately" they have newer version of the Evolution OS (V5.4.0.2R1 / V5.4.0.2R5). I read the memory statistics (via SSH):
                    1.) uptime 351 days / largest_fragment 9.38 MB / number_fragments 7
                    2.) uptime 315 days / largest_fragment 9.59 MB / number_fragments 1
                    3.) uptime 70 days / largest_fragment 9.47 MB / number_fragments 7
                    4.) uptime 49 days / largest_fragment 9.59 MB / number_fragments 4

                    Looking at these statistics, I do not believe that fragmentation is a problem. 9 MB should be enough for opening a FTP or SSH connection. So again the question: has the heap management been improved from V5.4.0.0R7 to V5.4.0.2R5?

                    Is there a possiblity to start a defragmentation of the heap memory when our application detects a fragmented heap memory pool? Rebooting should be the last possibility if the problem cannot be solved, because this is an non-scheduled downtime...

                    Comment


                    • #11
                      I agree - does not sound like a memory problem.
                      Please open a case with tech support so we can track this against your contact info.
                      Do you see other weird behavior besides SSH/SSL/HTTPS? Are other networking functions operating correctly? Are the devices static IP addressed or DHCP? Any idea how long the lease times were (DHCP)?
                      On your test devices with the longest uptimes, pull the XSR (status record) and add it to the bug, along with the XCR (configuration record) please.

                      Comment


                      • #12
                        Thank you. I submitted the problem to the technical support (with XCR/XCR of one test device).

                        When the problem occurs, other things seem to work correctly. There are only a couple of code fragments that use heap memory. All the other functions use stack memory or statical allocated pools. But I am not quite sure, because the HTTP status page cannot be generated.

                        The devices use static IP addresses.

                        Comment


                        • #13
                          BTW - are you doing any web page callbacks? Is the 400 error related to standard Lantronix web pages or to yours?

                          Comment


                          • #14
                            The image is linked with "evolution_no_web.lib". The HTTP request is a callback of our application. This callback does not allocate heap memory. Therefore I suspect the HTTP server to allocate memory for each client request (like the FTP and SSH server).

                            Comment


                            • #15
                              So, are you handling all of the web requests? The error is likely coming from HttpMalloc(). Please review your code and let me know what http API calls you are calling from your code. You can email those direct to me: garrym@lantronix.com

                              Comment

                              Working...
                              X