Announcement

Collapse

Contacting HomeSeer This Week

HomeSeer is open and operational this week. All orders are being processed and shipped as usual. However, some staff are working from home. If you need to contact HomeSeer for support or customer service, please use our Email or Chat options. https://homeseer.com/contact-us/
See more
See less

Linux* Mono and ASPX page compilation

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

  • MattL0
    replied
    What does this mean for us...and aspx pages?

    https://github.com/mono/mono/issues/...ment-534034094

    mono-basic is no longer maintained and it has been replaced with vbc compiler. Our CodeDom implementation will need to be updated to call it.

    Leave a comment:


  • w.vuyk
    replied
    I will still sync with your findings and compile on 4,5,2, just in case it matters. You found good results on 4.5.2, so syncing would exclude any doubts I guess? If any of you can check, at least it will strike out one possibility off the list.
    I am here waiting on one last users response and will release 2.0.4.5 after his answer. Doesn't hurt trying I guess

    Leave a comment:


  • bsobel
    replied
    Originally posted by w.vuyk View Post
    I am normally compiling at 4.5 here. I can do the next beta on 4.5.2 if it makes any difference? I do not change this normally as I had users with issues before when changing version.
    Wim
    4.5 is fine, the issue is with 4.6 and above... So that at least rules out the massive issue we see on those builds with Mono. Thanks, useful information to have (it turns out to be annoyingly tough to determine which .net versions was used just out of binaries...)

    Leave a comment:


  • w.vuyk
    replied
    I am normally compiling at 4.5 here. I can do the next beta on 4.5.2 if it makes any difference? I do not change this normally as I had users with issues before when changing version.


    Wim

    Leave a comment:


  • bsobel
    replied
    What is so strange is that the plugins truly run in a separate process, so the fact the HS is leaking suggests there exists some call from the plugin to HS causing this . One potential issue, it is possible the exception caused by the apparent net 4.0 and net > 4.5.2 on Mono leaks. JowiHue maybe simply retrying (as the exception doesn't happen every time).

    w.vuyk I apologize if you already answered this, what version of .net are you building against? Did you see my post on the 4.6(+) compatibility issue on Mono? If you are not on 4.5.2 (or less) is it possible for you to compile on 4.5.2.or do you require any libraries greater than 4.5.2? My system stability increased SUBSTANTIALLY after I had my own plugins plus a few others recompiled for 4.5.2, the constant errors went away. If you are on 4.6 or above, that could be a potential reason for what is being seen.

    Leave a comment:


  • MattL0
    replied
    Originally posted by bsobel View Post

    Matt can you do some basic debugging on the JowiHue config on your test system, set it up without a Hub, does the issue continue. Add the hub and then adjust the polling interval, see if the polling interval seems associated with the memory loss rate, etc? I also have the same issue, but don't currently have a blank test system setup to try and narrow it down. If we can get it a bit closer (hints, not root cause) I can try and dig in and see what we can figure out... I owe w.vuyk one for blaming him for something that wasn't his fault, so happy to help if I can...

    Hi Bill, I Cann't modify the polling interval since i am on deconz. Not the Philips hue hub.

    Note: The leak is there without theses two plugins. But the plugins call something surely more frequently in hs than other one ( maybe if i was using another x plugin intensively I would add it top the list ( just speculation)
    -to resume, plugins or wtv else call something in hs3 ( which depends on mono). If the call is done in a way that mono does not like , maybe hs3 process leak ( maybe not the best explanation but you got the logic).On windows it seems right, I tested it and i was stable if i remember correctly

    Analogy with hs3 script: some script works on windows here . But to make that work on linux you have to adapt the code. People says that Linux forgive less? ( it could also be a pure mono bug)





    All i can say is that the leak is very little on my system since i have removed mcsmqtt , and jowihue plugin , and replaced all off this with my own means ( sill have deconz devices and still use mqtt , i have the same functionality as before )( I use ws node red connection to receive status updates , i use node red to pool devce evry 20 mins in case ws connection missed something ) , i send theses value to hs3 devices by the json api) and sent value back with http put calls.
    One advantage of this is if a node die or wtv, i can change it with what i want without the need to modify any event in hs3 ( except the http put ones)


    For mqtt i replace mqtt device that were updating hs3 devcie value/string with hs json api, and i send value back to node red or other with bash script ( for now )


    all this took me something like 4 days ....in two period. so 2x 2 days. But i would qualify this as a patch

    ---


    So., yes I would like to help but rright NOW, we live in a basement we rent, And I the automation yesteday. We are moving to an apartment this week. I went to the new place to install the lutron and z wave light today.



    But is is possible i wont turn on automation for 1-2-3 months i can't know. + i do have some major thing to do in my life .
    For testing purpose, i will try , in the next weeks to load an old backup (i mean an Ssd backup) of when i had theses plugin installed . I will load mono 5.x , mono 6.0.0.319 ( or other : depends if they update it or not )
    And will try mono master too. Just let me know what you want me to try .

    Then when we finish testing , i will bring back my backup i just made 2 days ago . and update mono if necessary

    Just keep in mind it is hard for me to say when i will be available for those tests .


    thanks


    And thanks a lot for that generous offer Bill




    edti: Sorry iif there are mistakes/weird syntax, I was in a hurry and English is not my first language

    Leave a comment:


  • bsobel
    replied
    Originally posted by MattL0 View Post
    Thanks wim!! Yes i understand totally . This is also my opinion, the bug is there on other plugin two, but on a less very less severe scale.
    Matt can you do some basic debugging on the JowiHue config on your test system, set it up without a Hub, does the issue continue. Add the hub and then adjust the polling interval, see if the polling interval seems associated with the memory loss rate, etc? I also have the same issue, but don't currently have a blank test system setup to try and narrow it down. If we can get it a bit closer (hints, not root cause) I can try and dig in and see what we can figure out... I owe w.vuyk one for blaming him for something that wasn't his fault, so happy to help if I can...

    Leave a comment:


  • ZoRaC
    replied
    Originally posted by ZoRaC View Post
    Just downgraded Mono to 5.20.1. Got tired of rebooting every day.
    That minor leak in 5.x doesn’t bother me at all! Guess I’ll stick with this version for a few months.
    Click image for larger version

Name:	27D4F63E-5C72-4EAC-9768-FC818DCB0C79.png
Views:	125
Size:	6.5 KB
ID:	1320478

    Leave a comment:


  • ZoRaC
    replied
    Originally posted by ZoRaC View Post
    Btw, they haven’t tested HomeSeer on Mono 6.x - got an email from support today, after reporting a different bug. All “file pickers” now show files in random order instead of alphabetic...
    Just downgraded Mono to 5.20.1. Got tired of rebooting every day. That also solved my "file picker" issue.
    Click image for larger version

Name:	process.log.png
Views:	128
Size:	7.2 KB
ID:	1320465

    Leave a comment:


  • MattL0
    replied
    I am just at a loss of which person we should call for this?

    mono ? We just depend on their .Net integration. Seems hard to pin point the problem for them?

    hst. They always respond this is the first time someone report this and their linux box works without any leak (just chek the forum and the email you receive) .

    plugin author: depend on their knowledge on linux and this is understandable .

    enduser. I (we ) do not totaly understand the code involved . So all we can do is wait , wait, (or send. Vm and wait lol).

    Leave a comment:


  • MattL0
    replied
    Thanks wim!! Yes i understand totally . This is also my opinion, the bug is there on other plugin two, but on a less very less severe scale.

    Leave a comment:


  • w.vuyk
    replied
    Matthieu,

    I said this before, I do not know how to debug mono. I won't be of much use in this issue. Very willing to help with any other issue as you know, but this one is way out of my skill set.

    By the looks of this it might be a mono bug, as it only surfaces in mono and not in .NET or Windows. I have checked this by monitoring the usage of both memory and CPU in Windows where there is absolutely no issue on this level. I am by no means equipped for debugging mono, am only the .NET developer in this. So I do not see what I can add in the analysis as my knowledge in Linux/Mono is zero to nothing?

    The number of .NET libraries in use by HS and/or the JowiHue plugin are high, so it is unpredictable which .NET sublibrary is called more often and causing issues in mono. I am sure this goes for any plugin that is used. And if JowiHue and/or mscMQTT are hitting this leaking library more often then others then these plugins might look bad - but with the next mono bug it might be other plugins. I guess you need mono specialists for tracking this, who do know how to check on this, not a .NET developer?

    Wim




    Leave a comment:


  • MattL0
    replied
    Edit : Maybe hst can chime in too ? rjh

    Leave a comment:


  • MattL0
    replied
    Originally posted by ZoRaC View Post
    It’s a clear difference when running without JowiHue and mscMQTT:
    Click image for larger version  Name:	69BB7142-DE12-4575-9C0E-78D0C5826E3A.png Views:	0 Size:	5.7 KB ID:	1320168

    But that could be because they call the bugged Mono-code often?
    so that confirm my tests ! THanks a lot. Yes they surely call something... But I can't say what ...haha


    any thought of this Michael McSharry and w.vuyk ?

    Would it be possible for you to check this with the mono dev here : https://github.com/mono/mono/issues/15751 ? If you got the time.

    Just a recap:

    1. I think mono leaked in v 5
    2. I think they introduced a bigger leak in mono 6. which they tried to patch... but...
    3. I think hs process leak without your plugin too. But with your plugin is is just more intense.
    4. i think number 3 is true form mono 5 AND mono 6.

    Thanks


    Personally this the max i was able to do ( + we are moving to another place this week to i'll have to turn off the automation in the next hours), And i do not completely understand all the code involved in this, and what could be called in hs for it to leak. So I think , since you both are programmer , and your plugin are more sensible to the leak with mono, it should be easier for you to help the mono team ?

    Edit : Maybe hst can shime in too ?

    Leave a comment:


  • ZoRaC
    replied
    It’s a clear difference when running without JowiHue and mscMQTT:
    Click image for larger version

Name:	69BB7142-DE12-4575-9C0E-78D0C5826E3A.png
Views:	168
Size:	5.7 KB
ID:	1320168

    But that could be because they call the bugged Mono-code often?

    Leave a comment:

Working...
X