Hello,
Whenever I try to restore a file to a linux client from the server’s web interface the client’s gui crashes with a segmentation fault. If the gui is restarted it will crash almost immediately again until the client process is restarted. The client is running on slackware64 14.2 compiled from source. The server is 2.0.31 on the same version of linux. This also occurred in server 2.0.30 and client 2.0.29.
Here is a backtrace of the crash:
(gdb) run
Starting program: /usr/bin/urbackupclientgui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffe860e700 (LWP 2257)]
[New Thread 0x7fffe7e0d700 (LWP 2258)]
Thread 1 "urbackupclientg" received signal SIGSEGV, Segmentation fault.
0x00007ffff6b6a02d in wxTopLevelWindowGTK::RequestUserAttention(int) () from /usr/lib64/libwx_gtk2u_core-3.0.so.0
(gdb) bt
#0 0x00007ffff6b6a02d in wxTopLevelWindowGTK::RequestUserAttention(int) () at /usr/lib64/libwx_gtk2u_core-3.0.so.0
#1 0x0000000000433e31 in ()
#2 0x00007ffff6b68bfb in () at /usr/lib64/libwx_gtk2u_core-3.0.so.0
#3 0x00007ffff28d3073 in () at /usr/lib64/libglib-2.0.so.0
#4 0x00007ffff28d263a in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#5 0x00007ffff28d29b8 in () at /usr/lib64/libglib-2.0.so.0
#6 0x00007ffff28d2cd2 in g_main_loop_run () at /usr/lib64/libglib-2.0.so.0
#7 0x00007ffff4a20467 in gtk_main () at /usr/lib64/libgtk-x11-2.0.so.0
#8 0x00007ffff6b4a9c5 in wxGUIEventLoop::DoRun() () at /usr/lib64/libwx_gtk2u_core-3.0.so.0
#9 0x00007ffff6073673 in wxEventLoopBase::Run() () at /usr/lib64/libwx_baseu-3.0.so.0
#10 0x00007ffff6034966 in wxAppConsoleBase::MainLoop() () at /usr/lib64/libwx_baseu-3.0.so.0
#11 0x00007ffff60c6cc0 in wxEntry(int&, wchar_t**) () at /usr/lib64/libwx_baseu-3.0.so.0
#12 0x0000000000425932 in ()
#13 0x00007ffff4f507d0 in __libc_start_main () at /lib64/libc.so.6
#14 0x0000000000426019 in ()
(gdb)
I would guess this is mainly a wxGTK/GTK issue and I am assuming not many people use the GUI on Linux (and the tray icon doesn’t work on e.g. Ubuntu anyway).
That is probably true. But it would still be nice it it worked. Yesterday I had need to restore an accidentally deleted file on Linux. I have multiple redundant backup setups, UrBackup being one of those. So I thought I’d try the UrBackup restoration, simply because I never had (the website GUI based restore with the button click, that is).
I found that if the client gui is not running on the target Linux box (and in my case, it never is running, only the client backend), then the restore attempt will eventually time out. Then if you ever try to invoke the client gui later, it will immediately segfault. If the client gui happened to be running successfully when you attempt the restore, it immediately segfaults. Once it has segfaulted through either of these two scenarios, it will immediately segfault if you ever try to invoke it again (regardless if you are attempting a restore or not). The only way to stop the gui segfaulting is to kill/restart the backend. So we know that a restore attempt will kill the gui, but does this also mean that it is somehow distressing the backend? Since it is the backend (not the gui) that you have to restart to stop the segfaulting.
One of my major decision points in choosing a backup solution is if I can restore even if the backup software doesn’t work (as in this case with UrBackup). No proprietary backup formats or encryption allowed. And when researching UrBackup I found that I could easily restore using standard Linux command line stuff and would not require UrBackup itself during the restore process. So It passed the test, and got added to my suite of backup solutions that run redundantly.
Note that the client gui appears to be required for a restore (via the web interface clicking the restore button), since you have to acknowledge the restore attempt on the client. The only way I would expect to be able to do this is via the client GUI.
A newbie user would be confused and frustrated if they clicked on the restore button and it didn’t restore anything though. They may not know what to do in that case. It might be said though, that if a user has decided to run Linux, knows that they need to do backups, and actually found and installed UrBackup in the first place, that they are NOT a newbie and therefore might be capable of figuring out how to restore without any help from UrBackup. That would be good.
But it still would be nice if the UrBackup restore actually worked…