MacOS client 2020

Moisie · November 10, 2020, 8:33am

Thanks for the feedback Luca; I’ll add what you describe to my list of things to look into…

lucabrasi · November 13, 2020, 11:09am

Ok, let me know if I can help with some additional info

uroni · November 13, 2020, 4:19pm

@Moisie Could you look into that missing /Library/Application Support/UrBackup Client/var/urbackup/data ? A simple mkdir -p "/Library/Application Support/UrBackup Client/var/urbackup/data" in the postinst script should fix it, no?

Moisie · November 13, 2020, 8:13pm

@uroni Found the problem (my bad…), and just submitted a PR. Might be another couple of small tweaks coming along soon too.

Moisie · November 13, 2020, 8:58pm

Done.

uroni · November 15, 2020, 7:35pm

Updated version:

UrBackup Client 2.5.11 beta.pkg (6.0 MB)

Buzzz · November 16, 2020, 4:07pm

On 10.13.6, always the same problem, segmentation error when executing urbackupclientbackend
On 10.15.7, install OK, test OK

uroni · November 18, 2020, 5:59pm

With debug symbols: UrBackup Client 2.5.11 beta.pkg (7.1 MB)

Run with

lldb urbackupclientbackend
> run
> thread backtrace

Buzzz · November 19, 2020, 2:11pm

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)

nixcamic · November 20, 2020, 6:26pm

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.

uroni · November 20, 2020, 6:32pm

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.

nixcamic · November 21, 2020, 3:23pm

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

Moisie · December 1, 2020, 6:20pm

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…

Mathias_Gruber · December 4, 2020, 3:29pm

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

uroni · December 4, 2020, 3:33pm

Patches welcome. Thanks!

Mathias_Gruber · January 4, 2021, 12:39am

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.

Moisie · January 4, 2021, 8:16am

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

uroni · January 7, 2021, 6:24pm

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

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

Mathias_Gruber · March 13, 2021, 10:03am

@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.

Mathias_Gruber · March 13, 2021, 10:29am

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!