Description of problem: rapidsvn crashed when adding existed svn working copy. Run rapidsvn in terminal emulator will show "segmentation fault" when it crashed. Version-Release number of selected component (if applicable): 0.12.0-8.mga3 How reproducible: always Steps to Reproduce: 1.install rapidsvn 2.run rapidsvn 3.bookmarks -> add existing working copy a file select window will show up, after you select a svn working directory, rapidsvn will crash.
This also happens to me on Mageia 2. Version: 0.12.0-6.mga2 Steps to Reproduce 1. Install 2. Run 3. Repository -> Checkout 4. In window that pops up I enter my repo URL ( https://svn.code.sf.net/p/megamek/code/ ) file location ( /home/username/mm_svn/megamek ) while leaving all checkboxes at default 5. Press the OK button. 6. Status window says "Execute Checkout" and then program crashes. When run in a terminal I also get the same segfault mentioned by the OP. So... being a good little programmer myself I've gone and installed the debug symbols... and we get: (gdb) run Starting program: /usr/bin/rapidsvn [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Detaching after fork from child process 2923. Detaching after fork from child process 2924. Detaching after fork from child process 2925. [New Thread 0x7fffe7791700 (LWP 2926)] [New Thread 0x7fffdae1c700 (LWP 2961)] [New Thread 0x7fffda61b700 (LWP 2962)] [Thread 0x7fffdae1c700 (LWP 2961) exited] [Thread 0x7fffda61b700 (LWP 2962) exited] [New Thread 0x7fffda61b700 (LWP 3144)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe7791700 (LWP 2926)] 0x00007ffff595514b in svn_wc__db_wcroot_parse_local_abspath () from /usr/lib64/libsvn_wc-1.so.0 (gdb) bt #0 0x00007ffff595514b in svn_wc__db_wcroot_parse_local_abspath () from /usr/lib64/libsvn_wc-1.so.0 #1 0x00007ffff594f20b in svn_wc__db_temp_get_format () from /usr/lib64/libsvn_wc-1.so.0 #2 0x00007ffff59138da in svn_wc__internal_check_wc () from /usr/lib64/libsvn_wc-1.so.0 #3 0x00007ffff5b93d63 in svn_client__checkout_internal () from /usr/lib64/libsvn_client-1.so.0 #4 0x00007ffff5b93f80 in svn_client_checkout3 () from /usr/lib64/libsvn_client-1.so.0 #5 0x00007ffff5ba37cb in svn_client_checkout2 () from /usr/lib64/libsvn_client-1.so.0 #6 0x00007ffff7bc6ddc in svn::Client::checkout (this=<optimized out>, url= 0x7fffd4002818 "https://svn.code.sf.net/p/megamek/code", destPath=..., revision=<optimized out>, recurse=true, ignore_externals=false, peg_revision=...) at client_modify.cpp:61 #7 0x00000000004287e5 in CheckoutAction::Perform (this=0x950cc0) at checkout_action.cpp:135 #8 0x000000000047cf98 in ExecuteAction (this=0x8201c0) at threaded_worker.cpp:154 #9 ThreadedWorker::Data::Entry (this=0x8201c0) at threaded_worker.cpp:116 #10 0x00007ffff69829eb in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib64/libwx_baseu-2.8.so.0 ---Type <return> to continue, or q <return> to quit--- #11 0x00007ffff74ffb99 in start_thread () from /lib64/libpthread.so.0 #12 0x00007ffff60d90cd in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () (gdb) At which point I said screw it and moved on to using different software for the moment since I needed to work on my own project instead of trying to debug some arcane mistake that seems to be in libsvn_wc-1.so.0 and not directly in RapidSVN itself. Hopefully this helps ;)
CC: (none) => ralgith
I finally got around to installing the debug symbols / devel files for subversion/libsvn and I have a better gdb output, but I still don't know enough about this code right now to debug it further. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe7e2c700 (LWP 27706)] svn_wc__db_wcroot_parse_local_abspath (wcroot=0x7fffe7e2b7a8, local_relpath= 0x7fffe7e2b7b0, db=0x0, local_abspath= 0x929d80 "/home/dylan/mm_svn/megamek", result_pool=0x929738, scratch_pool= 0x929738) at subversion/libsvn_wc/wc_db_wcroot.c:382 382 probe_wcroot = apr_hash_get(db->dir_data, local_abspath, (gdb) bt #0 svn_wc__db_wcroot_parse_local_abspath (wcroot=0x7fffe7e2b7a8, local_relpath=0x7fffe7e2b7b0, db=0x0, local_abspath= 0x929d80 "/home/dylan/mm_svn/megamek", result_pool=0x929738, scratch_pool= 0x929738) at subversion/libsvn_wc/wc_db_wcroot.c:382 #1 0x00007ffff594f20b in svn_wc__db_temp_get_format (format=0x7fffe7e2b9d4, db=0x0, local_dir_abspath=0x929d80 "/home/dylan/mm_svn/megamek", scratch_pool=0x929738) at subversion/libsvn_wc/wc_db.c:10111 #2 0x00007ffff59138da in svn_wc__internal_check_wc (wc_format=0x7fffe7e2b9d4, db=0x0, local_abspath=0x929d80 "/home/dylan/mm_svn/megamek", check_path=0, scratch_pool=0x929738) at subversion/libsvn_wc/lock.c:95 #3 0x00007ffff5b93d63 in svn_client__checkout_internal (result_rev= 0x7fffe7e2bb48, url= 0x7fffc40017c8 "https://svn.code.sf.net/p/megamek/code", local_abspath= 0x929d80 "/home/dylan/mm_svn/megamek", peg_revision=0x7fffe7e2bbc0, revision=0x7fffe7e2bbb0, ra_cache=<optimized out>, depth= svn_depth_infinity, ignore_externals=0, allow_unver_obstructions=0, timestamp_sleep=0x0, ctx=0x900550, pool=0x929738) at subversion/libsvn_client/checkout.c:182 Looks like db is being passed null, but since I'm not sure what are valid values for this here I can't debug further due to time constraints. I'm pretty annoyed that this is still here though! C'mon team, fix this!
CC: (none) => balcaen.john, fundawang
Tested on Mageia 4 x86_64, the bug still here, RapidSVN is completly unusable: (gdb) run Starting program: /usr/bin/rapidsvn [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Gtk-Message: Failed to load module "canberra-gtk-module" Detaching after fork from child process 15714. Detaching after fork from child process 15715. Detaching after fork from child process 15716. [New Thread 0x7fffe78c1700 (LWP 15717)] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff589c0e7 in svn_wc_walk_status () from /lib64/libsvn_wc-1.so.0 (gdb) backtrace #0 0x00007ffff589c0e7 in svn_wc_walk_status () from /lib64/libsvn_wc-1.so.0 #1 0x00007ffff5b571d0 in svn_client_status5 () from /lib64/libsvn_client-1.so.0 #2 0x00007ffff5b28fa1 in svn_client_status4 () from /lib64/libsvn_client-1.so.0 #3 0x00007ffff5b2903b in svn_client_status3 () from /lib64/libsvn_client-1.so.0 #4 0x00007ffff5b290cd in svn_client_status2 () from /lib64/libsvn_client-1.so.0 #5 0x00007ffff7bcc8b6 in svn::Client::status(char const*, bool, bool, bool, bool, bool) () from /lib64/libsvncpp.so.3 #6 0x000000000044c30b in ?? () #7 0x000000000044cf21 in ?? () #8 0x00007ffff694e776 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /lib64/libwx_baseu-2.8.so.0 #9 0x00007ffff694e81b in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from /lib64/libwx_baseu-2.8.so.0 #10 0x00007ffff694eb87 in wxEvtHandler::ProcessEvent(wxEvent&) () from /lib64/libwx_baseu-2.8.so.0 #11 0x00007ffff6ed9228 in wxGenericTreeCtrl::Expand(wxTreeItemId const&) () from /lib64/libwx_gtk2u_core-2.8.so.0 #12 0x00007ffff6edb5e0 in wxGenericTreeCtrl::OnMouse(wxMouseEvent&) () from /lib64/libwx_gtk2u_core-2.8.so.0 ---Type <return> to continue, or q <return> to quit--- #13 0x00007ffff694e776 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /lib64/libwx_baseu-2.8.so.0 #14 0x00007ffff694e81b in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from /lib64/libwx_baseu-2.8.so.0 #15 0x00007ffff694eb87 in wxEvtHandler::ProcessEvent(wxEvent&) () from /lib64/libwx_baseu-2.8.so.0 #16 0x00007ffff694eb10 in wxEvtHandler::ProcessEvent(wxEvent&) () from /lib64/libwx_baseu-2.8.so.0 #17 0x00007ffff6ecb496 in wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) () from /lib64/libwx_gtk2u_core-2.8.so.0 #18 0x00007ffff6dca119 in gtk_window_button_press_callback () from /lib64/libwx_gtk2u_core-2.8.so.0 #19 0x00007ffff48414d5 in _gtk_marshal_BOOLEAN__BOXED () from /lib64/libgtk-x11-2.0.so.0 #20 0x00007ffff3db6188 in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #21 0x00007ffff3dc7b1d in signal_emit_unlocked_R () from /lib64/libgobject-2.0.so.0 #22 0x00007ffff3dcf4f9 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #23 0x00007ffff3dcfae2 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #24 0x00007ffff49513f4 in gtk_widget_event_internal () from /lib64/libgtk-x11-2.0.so.0 #25 0x00007ffff483fc84 in gtk_propagate_event () ---Type <return> to continue, or q <return> to quit--- from /lib64/libgtk-x11-2.0.so.0 #26 0x00007ffff484003b in gtk_main_do_event () from /lib64/libgtk-x11-2.0.so.0 #27 0x00007ffff44bb9bc in gdk_event_dispatch () from /lib64/libgdk-x11-2.0.so.0 #28 0x00007ffff3aee146 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #29 0x00007ffff3aee498 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 #30 0x00007ffff3aee89a in g_main_loop_run () from /lib64/libglib-2.0.so.0 #31 0x00007ffff483f127 in gtk_main () from /lib64/libgtk-x11-2.0.so.0 #32 0x00007ffff6db777a in wxEventLoop::Run() () from /lib64/libwx_gtk2u_core-2.8.so.0 #33 0x00007ffff6e34cdc in wxAppBase::MainLoop() () from /lib64/libwx_gtk2u_core-2.8.so.0 #34 0x00007ffff68fbf3d in wxEntry(int&, wchar_t**) () from /lib64/libwx_baseu-2.8.so.0 #35 0x0000000000421222 in main ()
CC: (none) => pyro_akmHardware: i586 => x86_64Version: Cauldron => 4
The problem seems fixed in 0.12.1 (backported from current Cauldron to Mageia 4). If anyone volunteers to test the package (explicitly in this bug), I can ask for a backport.
CC: (none) => olivier
I'm volunteer, how do I can test the pachage?
rapidsvn-0.12.1-3.mga4 just landed in core/backports_testing :) You should : * activate backports_testing in your sources from MCC * install rapidsvn * desactivaté backports_testing (you certainly don't want to update your system with all backports_testing) If it works, please say so, so we can publish the backport :)
Summary: rapidsvn crashed when adding existed working copy => Backport request: rapidsvn crashed when adding existed working copy
Also, I add that I made the backport myself as there was no maintainer. I'm now the maintainer of the package, but I don't use rapidsvn. If you don't report problems, I won't see them.
No crashes anymore! Tout semble bien fonctionner maintenant, RapidSVN est le meilleur client Subversion graphique que je connaisse. Merci Oliver.
I request a QA test of the backported rapidsvn 1.2.1 Submitted from: http://svnweb.mageia.org/packages?view=revision&revision=796528 Successfully built in backports_testing for Mageia 4: http://pkgsubmit.mageia.org/uploads/done/4/core/backports_testing/20141112000726.ofaurax.valstar.9352/ Pyro Arkham tested it OK, and the previous package was crashing on basic use. Please push Mageia 4 official backports.
Status: NEW => ASSIGNEDComponent: RPM Packages => BackportsAssignee: bugsquad => qa-bugsTarget Milestone: --- => Mageia 4
@Olivier: Sadly we can't validate backports because the way to handle them on the sysadmin side has not been sorted out yet. This rapidsvn update does justify a bugfix update, so I would advise to go through this channel: push to core/updates_testing (maybe also for mga3, there is still around ~1 week left before its EOL), and provide an update advisory. Have a look at https://wiki.mageia.org/en/QA_process_for_validating_updates for more details and an example of advisory.
CC: (none) => remi
rapidsvn-0.12.1-3.mga4 just landed in core/updates_testing for Mageia 4. Advisory: rapidsvn was crashing when adding an existing working copy. With this version, it doesn't anymore.
Good news.
Adjusting the bug as this is no longer a backport.
Component: Backports => RPM PackagesSummary: Backport request: rapidsvn crashed when adding existed working copy => rapidsvn crashed when adding existed working copy
Testing on Mageia4x64 real hardware using procedure found in Comment 1 With current package : -------------------- rapidsvn-0.12.0-8.mga3.x86_64 Procedure crashed with a segment fault. Updated to testing package : -------------------------- rapidsvn-0.12.1-3.mga4.x86_64 But : Program received signal SIGSEGV, Segmentation fault. Rechecked version : $ rpm -q rapidsvn rapidsvn-0.12.1-3.mga4 Not working then.
CC: (none) => olchal
Testing MGA4-64 on HP Probook 6555b. I installed rapidsvn-0.12.1 on a fresh system (as far as rapidsvn is concerned), thus never tried or installed rapidsvn-0.12.0. Ran the same test from Comment 1, and this completed successfully after downloading some 1.4 Gb. Does the new verion not completely overwrite the old one, or are some settings from the old version responsible?????
CC: (none) => herman.viaene
(In reply to Herman Viaene from comment #15) > Does the new verion not completely overwrite the old one, or are some > settings from the old version responsible????? Following your comment, I went through the packages needed by rapidsvn and I found that there was a problem with lib64svncpp3 after updating to testing package: $ rpm -q lib64svncpp3 lib64svncpp3-0.12.0-8.mga3 Enabling testing repos, I updated to : lib64svncpp3-0.12.1-3.mga4 which solved the problem. Rapidsvn doesn't show the segmentation fault anymore.
Whiteboard: (none) => MGA4-64-OK
Is anyone able to test on Mageia4 32bits? This way, we should be done, and the update could be pushed....
It's important to list rpm's aswell as the srpm with the advisory Olivier please. You can find an example here: https://wiki.mageia.org/en/Example_update_advisory_announcement Madb has them as.. i586: libsvncpp-devel-0.12.1-3.mga4.i586.rpm libsvncpp3-0.12.1-3.mga4.i586.rpm rapidsvn-0.12.1-3.mga4.i586.rpm x86_64: lib64svncpp-devel-0.12.1-3.mga4.x86_64.rpm lib64svncpp3-0.12.1-3.mga4.x86_64.rpm rapidsvn-0.12.1-3.mga4.x86_64.rpm SRPM: rapidsvn-0.12.1-3.mga4.src.rpm
Testing mga4 32 Before ------ Crash when following comment 1 $ rapidsvn Gtk-Message: Failed to load module "canberra-gtk-module" Segmentation fault After ----- All ok. Used to checkout current advisories from svn://svn.mageia.org/svn/advisories
Whiteboard: MGA4-64-OK => has_procedure MGA4-64-OK mga4-32-ok
Validating. I'll upload the advisory later. Please push to updates Thanks
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Advisory uploaded.
Whiteboard: has_procedure MGA4-64-OK mga4-32-ok => has_procedure advisory MGA4-64-OK mga4-32-ok
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2014-0217.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED