Announcement

Collapse
No announcement yet.

Any dev here would be able to answer the mono team ?

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

  • Any dev here would be able to answer the mono team ?

    https://github.com/mono/mono/issues/15751


    I do not know what to send them? I thought about a vm, but can't get anymore 30 days licences.

    Thanks

  • #2
    I have to say that's a big ask for Xamarin the Mono developers. Assuming you have disabled all your plugins and re enabled them one by one while checking memory usage each time I really think this would be a matter between HomeSeer, the plugin developers and Xamarin. Could you just pin the last known working version of Mono to your current install.

    Comment


    • #3
      Thanks. Just sent an email to hs3 , if it would be possible to send mono team a virtual machine to test with.


      Concerning the last mono. I prefer to stay on vs release build. they keep being updated ( contrary to snapshot), and they work like lts on linux, ''they are updated less often , but are tested more. '' + it has .net 4.7.2 so i'm fine.

      Comment


      • #4
        How familiar are you with Linux. The reason I ask is you could build/compile your own version of Mono if you feel the need to stay at the cutting edge.

        i read your posts on GitHub and was wondering the following

        What hardware and Linux flavour are you running HS3 on. It’s not completely clear from the posts you made on the GitHub. Also what version of HS3 are you running. Are you partaking in the current round of beta testing.

        I wouldn’t be entirely sure that HS3 and/or it’s plugins are 100% certified to run in Linux. As I see it you have Windows software with its accompanying plugins which have been modified to run under an open source platform. I don’t think that is the same but I do stand corrected.

        While I’m sure the Mono developers appreciate your findings you will find there’s very little they can do to help you directly bearing in mind that you are running a closed source commercial product on an open source platform.

        I’d be very interested to see what reply you received from the developers of HS3 and the plugin developers concerning your difficulties.

        Comment


        • #5
          If this is the reality of things , I will return to windows . I’m not alone that haves leaks on hs3 linux version. And I have tested the system on a vm, on debian, on ubuntu, on a arm platform . And I also see the leak on my mother computer (13 events 13 devices) (from a clean debian buster install )(it is less intense but it is here).


          My prod system is x64 Based . Ubuntu 19.04. The two plugins that makes mono having a leak on hs3 process, are Jowihue and mcsmqtt( i have replaced this one , I now send mqtt message with sh scripts, and I now uses http json api to receive info into hs3 ). I heard from other that other plugin I do not have leaks too.
          I do not feel I could compile my own version of mono.


          I’ll keep this post updated when i got more info from homeseer .

          Comment


          • #6
            I'd certainly leave the interoperatibility of HS3 and Mono with the devs and the Mono developers. They have their own platforms for resolving issues like these. We'd need to build some form of metrics to gauge memory leaks and the effects they have on each Linux users HS3 install. We could report our findings back to the forum and allow the devs to investigate further. You'll find the GitHub extremely technical and sometimes quite daunting.

            Comment


            • #7
              dev do not want to test on linux. got no reply. Yes i have the same opinion. Devs should go on the github and report their own test... but it is what it is..

              Comment


              • #8
                MattL0 Appreciate your work on this and hope you have more success than I did. I went down a similar path and also found the HomeSeer developers non interested in resolving issues with the latest versions of Mono and have had to remain on a very outdated Mono version 5.0.1.1. My issue was that HomeSeer would not properly render ASPX pages.

                I worked with Michael McSharry (developer of mcsMQTT) to make the plugin more linux friendly and he was very responsive. Recommend reaching out to him and let him know the issue. He might be willing to help and interface with Mono developers.

                Comment


                • #9
                  Originally posted by mwolter View Post
                  MattL0 Appreciate your work on this and hope you have more success than I did. I went down a similar path and also found the HomeSeer developers non interested in resolving issues with the latest versions of Mono and have had to remain on a very outdated Mono version 5.0.1.1. My issue was that HomeSeer would not properly render ASPX pages.

                  I worked with Michael McSharry (developer of mcsMQTT) to make the plugin more linux friendly and he was very responsive. Recommend reaching out to him and let him know the issue. He might be willing to help and interface with Mono developers.
                  Hi , thanks.

                  I know there a workaround from bsobel for the aspx page . Just write ‘’mono aspx ‘’ on the search field of the forum. But if you are on arm, the issue still persist i think.


                  Yes I am quite happy that someone took a look at the VM I made for them (mono team) I know that jowihue and mcsmqtt are leaking the hs3 process (maybe some other plugin but the impact is almost null.) my theory is that any plugin that update/poll hs3 devices values will leak the the hs3 process too. So, knowing these two are updating/polling the hs3 devices a lot ...maybe this is the reason...maybe not. Or maybe it is just a garbage collection issue....maybe both reason are valid here too.

                  I have completly removed those plugins from my production system and the leak seems to be away now (but. Have just tested this setup with mono 5.18.1.28 (not 6.0.0.313) ) I do use deconz and mqtt but with other means. The system is as fonctional as before , but with no leak (I first have removed mcsmqtt, than removed jowihue..now I need to get data for more than one day to be sure). And a LOT less load on the cpu.

                  If mono team is able to find the issue with memory, then the plugin devs wont have to take a look at it (I hope) .

                  yes I remember your messages between you and Michael ! The plugin changed a lot after this, and it was really more user friendly. I know micheal is openmind, But at the same time , if the issue is really on mono side , then I wont bother him more.

                  Comment


                  • #10
                    Seems like things are moving !!

                    https://github.com/mono/mono/issues/15751

                    See : https://github.com/BrzVlad/mono/comm...e4ec541fda646f

                    And https://github.com/mono/mono/pull/15935

                    Comment


                    • #11
                      Seems like the issue was there ? https://github.com/mono/mono/commit/...0f56f374b74a2b

                      Comment


                      • #12
                        This may be of interest to you. https://www.mono-project.com/docs/advanced/embedding/

                        Comment


                        • #13
                          OK I managed to build mono from source myself ( from master). Had to build some more dependencies after ( ex : vbnc, libgdiplus0) and needed to create a simlink for the plugins to be able to load, since the plugins calls ''mono'' ( the symlink is linked to /usr/bin/mono), but i made myself a bash script I can easily modify.
                          I also had to generates cert with this command from the new mono folder.
                          Code:
                           ./cert-sync /etc/ssl/certs/ca-certificates.crt
                          Certificates and libgdiplus0 where needed for ak google calendar plugin.
                          I do not know when they will do a build with the fixe, and i know The memory leak fix from mono 6.0 have been put into master ( and backported in two other branches)...so I tried to compile myself.

                          The main compilation took like 30 minutes I think ( with samsung m2 ssd and Amd 2700x cpu)... I can't imagine compiling this on a raspberry pi LOL.

                          Memory seems stable. But will report after waiting a little more.


                          The ''hardest'' part was to stop myself.. and take a moment to understand the variable logic in the bash files . I am not a programmer lol.

                          Comment


                          • #14
                            Originally posted by concordseer View Post
                            Thanks!
                            HSt should know about this !

                            But this is for now a little complicated for me lol. And I think you have to be able to access non compiled source code ( i Mean the one from homeseer) for this?

                            Comment


                            • #15
                              The memory leak induced by mono v6.x.x.x seems to be gone ! I tested this very same config with mono 6.0.0.0313 before compiling and the memory after 2 hours was already near 200mb. So I suspect it to be more after 3h.

                              Now it seems as stable as mono 5.x.x.x. ( see picture)

                              So..

                              The config with jowihue plugin and mcsmqtt activated, on mono 5.x.x.x was leaking the hs3 process.
                              The config with jowihue plugin and mcsmqtt deactivated, on mono 5.x.x.x was NOT ( if there was a leak it was little) leaking the hs3 process . Did not test long
                              The config with jowihue plugin and mcsmqtt activated, on mono 6.0.0.113 was leaking the hs3 process A LOT
                              The config with jowihue plugin and mcsmqtt activated, on mono 6.0.0.113 was leaking the hs3 process.

                              Finally , The config with jowihue plugin and mcsmqtt deactivated, on mono 6.5 (compiled today) is not leaking the hs3 process.
                              The leak induced in mono 6.0.0.313 seems to have a different cause than the one I was seeing in mono 5.x.x.x. In other words, I think a leak was present in mono 5.x.x.x , and the one from 6.0.0.313 exacerbated the the one already here ( in an additive ( independent effect) manner : I mean I do not think there is an interactive effect on memory, between leak sources here)

                              So..

                              A day, this summer i will load the jowihue plugin and see if the hs3 process is leaking the same manner on the compiled version of mono, versus when the config was on mono 5.x.x.x.x. This plugin do updates devices frequently, without any events needed to be configured... so it'll be less time consuming to test only that one.


                              note: I am trying to do all tests without opening the web based hs3 gui. I know ( I guess from what i saw) that this impact memory consumption and gc collection.




                              Attached Files

                              Comment

                              Working...
                              X