-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
U 20.04 for binary build & release #232
Conversation
Build and GitHub release to 20.04
👍 |
does this fix anything? |
I hope for it. The only difference between the auto-build and my manual was the rust version:
|
👍 |
added |
Hi, I'm trying to use this on FreeBSD, also creating a port. I'm building in poudriere, but the resulting binaries core dump. I'm building and running on The rust compiler I'm using is version Any suggestions on how to solve this or help diagnose? |
There's an interesting issue on FreeBSD, if you run the binaries from other than bash it core dumps (started with csh, then tested with tcsh and sh too). I've shared my previous build at a temp. repo here - this are just running for me, and the service script can sart/stop/restart - but my user's shell set to bash. Please check it out if you have the same result, eg. binaries hbbs|r runs if you do:
|
I have discovered PR #209 while you were replying. I see he has also patched the software with a very simple change, which I'm going to test. I'll also test with bash ot screen (or maybe tmux) if necessary. Thanks for the suggestions. |
Okay, before you use the patch, make sure you have the same backtrack output from the core dump - because I don't. I only have stack overflow and more generic code references. I'll put up, here is you need it. core dump check:
|
Made a fresh build, it still works here with bash (errors cause of previous build is running as service)
@madpilot78 can you share your core dump output, so we can compare them? |
with a debug build I get the backtrace at the tail of this comment. An interesting line is:
that file also has a (In fact I misunderstood the patch from #209 on first try)
|
I confirm that changing Should I send it as a pull request? |
IMHO: Hard to say :(
I don't know what is the main differenece between Maybe something should be changed in the flexi_logger library (https://docs.rs/flexi_logger/latest/flexi_logger/) not in the rustdesk-server? I think taht if you are creating port fo FreeBSD you can add the patch to change this line before compile. It is rather the workaround not the solution. |
@mickeyreg I'm already testing this as a local patch in the port. I find it easier to compile and install software in FreeBSD leveraging ports anyway, even for personal use, than building them by hand. I have no development experience in rust, I actually don't know the language. I can barely understand something of it just because it is very similar to C/C++, but I could suggest using an |
@madpilot78 , @mickeyreg Here's a fresh execution with /bin/tcsh as shell for the user:
|
@n-connect : You have the same error in the backtrace. frame #9: 0x00000000011c8fea hbbr`hbbr::main::h9a752489a163aaf3 + 586 and thread #3, name = 'flexi_logger-async_', stop reason = signal SIGSEGV Make a debug build ( |
If |
That's the Github Actions' auto build on mine. Yep, it has it at the beginning I'm still interested why it is happening. Another rust code also using flexi_logger has none of these issues, nor needs workarounds notify_push. They are not using the @rustdesk it is not about completely removing flexi_logger, @mickeyreg & @madpilot78 changed & tested: if we change the code to directwrite from async it works.
|
IMHO, it'll be a good idea to directly log to syslog, at least on linux. |
RustDesk-server is a self hosted server for the RustDesk remote desktop software. WWW: https://rustdesk.com/server/ Patches obtained from/discussed in: rustdesk/rustdesk-server#232 rustdesk/rustdesk-server#209
In the while I have added rustdesk-server to the FreeBSD ports collection: https://www.freshports.org/net/rustdesk-server/ I have included the patches discussed here for now, and done slight modifications to the startup scripts. I configured it to log via syslog and the port also installs syslog and newsyslog configuration files (users can customize them later, obviously). Feel free to take what you like. I also regenerated the lock file. The one in the repo looks outdated, and was confusing the ports cargo helpers. Nothing is set in stone though, so if better patches are submitted here or to the port I will adopt them and submit them here also. |
@madpilot78 great, thx of taking care of that world, I kinda never started to use the ports, would take too much time. Check #233 , made the change @mickeyreg found out, along with a simple check to do it for FB only, so no other platforms affected -> those will remain Async. Also took your rc.d script variable optimizations too. @rustdesk the FB core dump issue fixed. |
FWIW I have an old FreeBSD port (v1.1.5) that use only this patch:
|
Thanks, do you know where the "dont_minimize_extra_stacks" option should be applied / where/how the port system would put it? Or can you share the sources of the port v1.1.5? I've made some workaround in #233 , but would be good to know if there's a better approach, or if that actually pinned the root cause. (The 2nd thing I am curious about, how that v1.1.5 port worked with the old local-ip-address dependency from 2022-05-22 on FB, the version officially supported FreeBSD release in 2022-12-30 a v0.5.0 - but that another story :) ) |
I've pushed my (very old) port here: https://github.com/MikaelUrankar/rustdesk-server-ports I don't know what the problem is with the local-ip-address. |
@MikaelUrankar Looks like the lock file was not updated to account for the update in the Regarding the |
dont_minimize_extra_stacks is explained here https://github.com/emabee/flexi_logger#dont_minimize_extra_stacks |
Thx for the pieces. The "dont_minimize_extra_stacks" seems to connected our core dump based on this thread 'flexi_logger-flusher' has overflowed its stack #95. Poster has issues with WriteMode::BufferAndFlush and moved on with Async. Will try with the option "dont_minimize_extra_stacks" in here with Cargo.toml, to see if it makes a difference |
I can confirm the "dont_minimize_extra_stacks" option in Carg.toml does the trick: no code change required in main.rs/hbbr.rs for "WriteMode::Direct" necessary. The binaries run under csh without core dump. @mickeyreg @madpilot78 @paspo please do test it. If it works for your too it makes my latest PR #233 partly unnecessary. Cargo.toml from: My test run with that:
|
@n-connect Yes, using I have had no time to perform more thorough testing. |
@madpilot78 thx, you are on amd64 13.1-p7 if I remember right, correct? |
@n-connect exactly. |
@mickeyreg @paspo can you test it too? I've uploaded an updated tar.gz with my build according to |
While, its happening the next interesting thing is finding out, if the Github Actions build will also work without core dump? That build still produce a binary for FB v12.3, however the toolchain version set from 1.62 to 1.67.1 - highest available in U20.04 builder/runner VM. |
Please note that FreeBSD 12.3 is reaching EoL today, minimum supported version is 12.4, which will EoL at the end of the year. |
@n-connect , copied from @madpilot78: Yes, using I have had no time to perform more thorough testing. ;) |
Yep, you're right - and that's why I wrote this very PR. Its the repo owner who needs some convincing on EoL stuff, but he/she(?) agreed finally :). I wanna know why the rust binaries built by GitHub Actions "compiled for" v12.3. This very PR #232 raised the Ubuntu VM version to be able use higher rust and toolchain (U20.04 vs U22.04 is rust 1.67.1 vs rust 1.68 - see below my build with 1.67.1 are looking good). Okay, here's the road so far (Supernatural series, anyone?):
Thanks everyone again. Now we (I), want a good autobuild here in Github as the original code hosted here. So the GH Actions' autobuild. after this very PR merged - still gives this kind of binary:
My manual builds with rust 1.67.1 give this:
|
Modify patch, needed to avoid crashes on startup, to improved one, discussed in upstream PR. Adding the "dont_minimize_extra_stacks" option to the flexi_logger avoids the stack overflow causing the startup crashes. Obtained from: rustdesk/rustdesk-server#232 (comment)
I have actually updated the FreeBSD port to use @MikaelUrankar patch, since it works fine. |
@n-connect I admit that making the port took me some time, I had been working on it for a few weeks, but due to other things I was putting little time/effort in it, I just sprinted it these days, also because I needed it t use it myself. And it's working like a charm, I must say. I also plan to work on a port for the desktop client, but that will not happen anytime soon I suspect. I looks a little more complex. |
Flexi_logger options for async writemode rustdesk#232 (comment)
In the meantime:
|
RustDesk-server is a self hosted server for the RustDesk remote desktop software. WWW: https://rustdesk.com/server/ Patches obtained from/discussed in: rustdesk/rustdesk-server#232 rustdesk/rustdesk-server#209
Modify patch, needed to avoid crashes on startup, to improved one, discussed in upstream PR. Adding the "dont_minimize_extra_stacks" option to the flexi_logger avoids the stack overflow causing the startup crashes. Obtained from: rustdesk/rustdesk-server#232 (comment)
Build and GitHub release to 20.04