MacOS client 2020

iMac-de-BUZZZ:sbin atelier$ lldb urbackupclientbackend
(lldb) target create “urbackupclientbackend”
Current executable set to ‘urbackupclientbackend’ (x86_64).

(lldb) run
Process 2190 launched: ‘/Applications/UrBackup Client.app/Contents/MacOS sbin/urbackupclientbackend’ (x86_64)
Process 2190 stopped

  • thread #1, queue = ‘com.apple.main-thread’, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007fff53980232 libsystem_c.dylibstrlen + 18 libsystem_c.dylibstrlen:
    -> 0x7fff53980232 <+18>: pcmpeqb (%rdi), %xmm0
    0x7fff53980236 <+22>: pmovmskb %xmm0, %esi
    0x7fff5398023a <+26>: andq $0xf, %rcx
    0x7fff5398023e <+30>: orq $-0x1, %rax
    Target 0: (urbackupclientbackend) stopped.

(lldb) thread backtrace

  • thread #1, queue = ‘com.apple.main-thread’, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    • frame #0: 0x00007fff53980232 libsystem_c.dylibstrlen + 18 frame #1: 0x00000001000030a5 urbackupclientbackendstd::__1::char_traits::length(char const*) + 21
      frame #2: 0x00000001004bb621 urbackupclientbackendstd::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string<std::__1::nullptr_t>(char const*) + 49 frame #3: 0x00000001004a0dbd urbackupclientbackendstd::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >::basic_stringstd::__1::nullptr_t(char const*) + 29
      frame #4: 0x00000001004a40a7 urbackupclientbackendmain + 567 frame #5: 0x00007fff53930015 libdyld.dylibstart + 1
      frame #6: 0x00007fff53930015 libdyld.dylib`start + 1
      (lldb)

Is this client compatible with UrBackup server 2.4.13? It took forever for me for it to connect to a local server, then after a couple hours it dropped the connection and wouldn’t connect at all. I couldn’t get it to work at all with an internet server.

I thought the file size is larger, so it must have debug data… but that wasn’t the case. This one should have debug data:

UrBackup Client 2.5.11 beta.pkg (6.3 MB)

It might not be.

I’d assume recommended server is 2.5.17 for this client?

Hi:

I’ve run the debug package on macOS 10.13.6, with this outcome:

admin$ lldb /Applications/UrBackup\ Client.app/Contents/MacOS/sbin/urbackupclientbackend
(lldb) target create "/Applications/UrBackup Client.app/Contents/MacOS/sbin/urbackupclientbackend"
Current executable set to '/Applications/UrBackup Client.app/Contents/MacOS/sbin/urbackupclientbackend' (x86_64).
(lldb) run
Process 1153 launched: '/Applications/UrBackup Client.app/Contents/MacOS/sbin/urbackupclientbackend' (x86_64)
Process 1153 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007fff66e66232 libsystem_c.dylib`strlen + 18
libsystem_c.dylib`strlen:
->  0x7fff66e66232 <+18>: pcmpeqb (%rdi), %xmm0
    0x7fff66e66236 <+22>: pmovmskb %xmm0, %esi
    0x7fff66e6623a <+26>: andq   $0xf, %rcx
    0x7fff66e6623e <+30>: orq    $-0x1, %rax
Target 0: (urbackupclientbackend) stopped.
(lldb) thread backtrace
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007fff66e66232 libsystem_c.dylib`strlen + 18
    frame #1: 0x00000001002c312e urbackupclientbackend`main + 942
    frame #2: 0x00007fff66e16015 libdyld.dylib`start + 1
    frame #3: 0x00007fff66e16015 libdyld.dylib`start + 1

For the record, I get the same behaviour on macOS 10.12.3 (backend dies with a Segmentation fault when run from Terminal) - but I know it works on macOS 10.12.6. Will investigate further and report back…

strlen() called with a NULL pointer, called at 942 bytes offset from main() start. Seems very simple to fix.

Patches welcome. Thanks!

Ok. As I do not have a Mac I ended up building a Hackintosh and managed to compile server and clients. Pull requests has been made on your GitHub repo. Problems are related to hard-coded absolute paths. App Bundles uses relative paths to access icons and all other resources.
Because of the required notarization I’m unable to test the final setup pkg.

2 Likes

Many thanks @Mathias_Gruber - your help here is much appreciated!

Thanks! (Non-mac users to the rescue :wink: ).

It’ll take a bit unfortunately till I can build a new signed pkg currently.

1 Like

@uroni: Trying with the last version, this problem or similar, still happens.
I’ve back-traced the call stack:

_std::__1::char_traits<char>::length(char const*)
_std::__1::list<TCLAP::Arg*, std::__1::allocator<TCLAP::Arg*> >::push_front(TCLAP::Arg* const&)
_TCLAP::SwitchArg::combinedSwitchesMatch(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&)
_void TCLAP::ClearContainer<std::__1::list<TCLAP::Visitor*, std::__1::allocator<TCLAP::Visitor*> > >(std::__1::list<TCLAP::Visitor*, std::__1::allocator<TCLAP::Visitor*> >&)

This hits the TCLAP library. I’ve saw that a newer version is available. Maybe updating it, could fix this.

A second back-trace, this time with input command line arguments, points to the same source:

_std::__1::vector<SCacheItem, std::__1::allocator<SCacheItem> >::max_size() const
_std::__1::vector<SCircularLogEntry, std::__1::allocator<SCircularLogEntry> >::resize(unsigned long)
_std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::erase(std::__1::__tree_const_iterator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, void*>*, long>)
_void TCLAP::ClearContainer<std::__1::list<TCLAP::Visitor*, std::__1::allocator<TCLAP::Visitor*> > >(std::__1::list<TCLAP::Visitor*, std::__1::allocator<TCLAP::Visitor*> >&)

Hope it helps!

I’d run it with asan to get a better error location (compile with -fsanitize=address in CPPFLAGS + LDFLAGS). Your stack trace is also missing files:lines and doesn’t make much sense…

I am running on a debug environment here and interestingly I have a crash in the std::string getSystemServerName(bool use_fqdn) method.
Specifically inside fgets. I checked docs but cannot find an error, but it is 100% reproducible. I will try a bit harder.
Aside of that, I found an error in cmdline_preprocessor.cpp @230:

if (argc > 0 &&
	std::string(argv[1]) == "--internal")

The correction is argc > 1.

I think the buffer needs to be zero initialized (add = {}).

char hostname_appl[MAX_PATH + 15] = {};

and

char buf[4096] = {};

The Linux man for fgets has this

A terminating null byte (aq\0aq) is stored after the last character in the buffer.

… but I cannot see it in the macos manual…

Could be this is how I got that random slash into the serial id

So I finally made a patch and it worked. The problem is that a popen is made for the first command and before a pclose happens a another nested popen is made.

Look at the FreeBSD docs for the popen on the section bugs. This is supposedly the cause of the problem.

My first test is working now. I will review the code and clean it up. Then I’ll send you a PR.

When I start the Mac client, I get the error "The application “UrBackup Client.app” is not open anymore. When I start the Mac Client from Terminal, I get the error “LSOpenURLsWithRole() failed with error -600 for the file /Applications/UrBackup Client.app.”

MacOS = 10.15.7

Please use the client in MacOS client 2021