Thank you! I nearly didn't find this, as it depended on some random value whether it would crash or not. It turned out it was triggered off by the "&" character in the label one of of a commands. I've fixed the bug, any characters are now ok in labels. in git now.
Richard On Mon, 2015-09-21 at 16:02 +0200, Andreas Schneider wrote: > Here is the back trace: > > Program received signal SIGSEGV, Segmentation fault. > strlen () at ../sysdeps/x86_64/strlen.S:106 > 106 ../sysdeps/x86_64/strlen.S: Datei oder Verzeichnis nicht gefunden. > (gdb) where > #0 strlen () at ../sysdeps/x86_64/strlen.S:106 > #1 0x00007ffff591c888 in gtk_text_buffer_set_text () > from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #2 0x00000000004629c1 in ?? () > #3 0x00007ffff5971e02 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #4 0x00007ffff5971e93 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #5 0x00007ffff59727c5 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #6 0x00007ffff5972c2c in gtk_tree_selection_select_path () > from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #7 0x00007ffff5972d11 in gtk_tree_selection_select_iter () > from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #8 0x00007ffff598a641 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #9 0x00007ffff598ad74 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #10 0x00007ffff404a245 in g_closure_invoke () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #11 0x00007ffff405bf6c in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #12 0x00007ffff4064778 in g_signal_emit_valist () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #13 0x00007ffff4064f2a in g_signal_emit_by_name () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #14 0x00007ffff57edee1 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #15 0x00007ffff57f1d5e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #16 0x00007ffff404a245 in g_closure_invoke () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #17 0x00007ffff405be62 in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #18 0x00007ffff4064778 in g_signal_emit_valist () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #19 0x00007ffff4064f2a in g_signal_emit_by_name () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #20 0x00007ffff57ebf55 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #21 0x00007ffff57f1630 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #22 0x00007ffff404ced0 in g_cclosure_marshal_VOID__STRINGv () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #23 0x00007ffff404a474 in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #24 0x00007ffff4064087 in g_signal_emit_valist () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #25 0x00007ffff4064f2a in g_signal_emit_by_name () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #26 0x000000000045f0c7 in ?? () > #27 0x00007ffff404a474 in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #28 0x00007ffff4064087 in g_signal_emit_valist () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #29 0x00007ffff40649df in g_signal_emit () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #30 0x00007ffff5789a3d in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #31 0x00007ffff5789a95 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #32 0x00007ffff404a474 in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #33 0x00007ffff4064087 in g_signal_emit_valist () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #34 0x00007ffff40649df in g_signal_emit () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #35 0x00007ffff5787a20 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #36 0x00007ffff1e19dc0 in ffi_call_unix64 () > from /usr/lib/x86_64-linux-gnu/libffi.so.6 > #37 0x00007ffff1e19828 in ffi_call () > from /usr/lib/x86_64-linux-gnu/libffi.so.6 > #38 0x00007ffff404aebc in g_cclosure_marshal_generic_va () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #39 0x00007ffff404a474 in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #40 0x00007ffff4064087 in g_signal_emit_valist () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #41 0x00007ffff40649df in g_signal_emit () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #42 0x00007ffff582c1c1 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #43 0x00007ffff404d233 in g_cclosure_marshal_VOID__BOXEDv () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #44 0x00007ffff404a474 in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #45 0x00007ffff4064087 in g_signal_emit_valist () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #46 0x00007ffff40649df in g_signal_emit () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #47 0x00007ffff582997e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #48 0x00007ffff582adcb in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #49 0x00007ffff582d610 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #50 0x00007ffff5800ebb in gtk_event_controller_handle_event () > from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #51 0x00007ffff599c46d in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #52 0x00007ffff586f44e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #53 0x00007ffff404a474 in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #54 0x00007ffff4063b30 in g_signal_emit_valist () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #55 0x00007ffff40649df in g_signal_emit () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #56 0x00007ffff599fe34 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #57 0x00007ffff586cd5e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #58 0x00007ffff586e96e in gtk_main_do_event () > from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #59 0x00007ffff5416b72 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #60 0x00007ffff3b72c5d in g_main_context_dispatch () > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #61 0x00007ffff3b72f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #62 0x00007ffff3b73272 in g_main_loop_run () > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #63 0x00007ffff586dc25 in gtk_main () > from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #64 0x000000000047cd3d in ?? () > #65 0x00007ffff7a5d959 in ?? () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #66 0x00007ffff7b08caa in ?? () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #67 0x00007ffff7adc5f5 in ?? () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #68 0x00007ffff7b13352 in ?? () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #69 0x00007ffff7b37aec in ?? () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #70 0x00007ffff7a680f0 in scm_call_4 () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #71 0x00007ffff7b08b01 in scm_catch_with_pre_unwind_handler () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #72 0x00007ffff7b08d82 in scm_c_catch () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #73 0x00007ffff7a5d7bd in ?? () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #74 0x00007ffff7a5da68 in scm_c_with_continuation_barrier () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #75 0x00007ffff7b05c45 in ?? () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #76 0x00007ffff7795102 in GC_call_with_stack_base () > from /usr/lib/x86_64-linux-gnu/libgc.so.1 > #77 0x00007ffff7b05d1f in ?? () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #78 0x00007ffff7b05d4b in scm_with_guile () > from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22 > #79 0x0000000000415a13 in main () > > When I rename my .denemo-1.2.5 directory and therewith start with a > clean configuration, the crash happens anyway (with similar back trace). > I am using a Debian stable (Jessie) system. > > Andreas > > > Am 21.09.2015 um 15:08 schrieb Richard Shann: > > I can't get this to happen on my current build, nor on a windows build > > 1.2.5 that I've been testing. > > I have an idea it may be possible to get that if the set of commands > > that you have is in some way scrambled (something like the file > > denemoui.xml referring to non-existent commands, or Default.commands > > having something bad in it)... I'm really not sure, but try to test on a > > completely clean system. (Alternatively - or even additionally - the > > output from gdb's where command would be interesting...) > > > _______________________________________________ > Denemo-devel mailing list > Denemo-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/denemo-devel _______________________________________________ Denemo-devel mailing list Denemo-devel@gnu.org https://lists.gnu.org/mailman/listinfo/denemo-devel