Menu

#127 Geany Debugger Crashes on Run - trunk (1.25x)

trunk
closed-duplicate
nobody
debugger (11)
5
2015-02-12
2015-02-06
Ron Brash
No

Geany crashes when pressing RUN in the debug panel. Built with trunk geany and plugins.

PS autotool for debugger - it cannot find vte.h, but in Ubuntu 14.04.1 libvte-dev puts the header here: /usr/include/vte-0.0/vte/vte.h

[rbrash@ackbar:~/source/geany-plugins] $ gdb geany
GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from geany...done.
(gdb) run
Starting program: /usr/local/bin/geany
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffee4bb700 (LWP 10017)]
[New Thread 0x7fffedcba700 (LWP 10018)]
[New Thread 0x7fffed4b9700 (LWP 10019)]
[New Thread 0x7fffeccb8700 (LWP 10020)]
[New Thread 0x7fffd26f7700 (LWP 10022)]
[Thread 0x7fffed4b9700 (LWP 10019) exited]

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed

(geany:10013): GLib-CRITICAL **: Source ID 1243 was not found when attempting to remove it

Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
32 ../sysdeps/x86_64/multiarch/../strchr.S: No such file or directory.
(gdb) backtrace

0 __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32

1 0x00007fffdcca625a in on_read_from_gdb ()

from /usr/local/lib/geany/debugger.so

2 0x00007ffff60bbb6d in g_main_context_dispatch ()

from /lib/x86_64-linux-gnu/libglib-2.0.so.0

3 0x00007ffff60bbf48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

4 0x00007ffff60bc272 in g_main_loop_run ()

from /lib/x86_64-linux-gnu/libglib-2.0.so.0

5 0x00007ffff78bc747 in gtk_main ()

from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0

6 0x0000000000451f36 in main (argc=1, argv=0x7fffffffe048) at main.c:1236

Discussion

  • Colomban Wendling

    • labels: --> debugger
    • status: open --> closed-duplicate
     
  • Colomban Wendling

    Duplicate of [#112]. debugger currently crashes with GDB >= 7.7.

    PS autotool for debugger - it cannot find vte.h, but in Ubuntu 14.04.1 libvte-dev puts the header here: /usr/include/vte-0.0/vte/vte.h

    It's weird that it would be a problem, it uses pkg-config so there's no reason it could be wrong anywhere. Also, how did you build Debugger if it didn't find VTE, as IIUC it's a required dependency?
    BTW, are you certain you positive you have libvte-dev, not libvte-2.90-dev?

     

    Related

    Bugs: #112

  • Ron Brash

    Ron Brash - 2015-02-06

    I don't have the libvte-2.90-dev package installed; although the "regular" library is installed.

    libvte-2.90-9 is already the newest version.
    libvte-2.90-common is already the newest version.
    libvte-common is already the newest version.
    libvte-common set to manually installed.
    libvte-dev is already the newest version.
    libvte-doc is already the newest version.
    libvte-doc set to manually installed.
    libvte9 is already the newest version.

    I compiled it by passing VTE_CFLAGS=-I<the path> to ./configure and then make, sudo make install. Initially, the debugger so was not compiled, so I dug into the debugger directory and manually executed the autotool generated Makefile which resulted in finding that <vte/vte.h> was missing,

     

    Last edit: Colomban Wendling 2015-02-06
    • Colomban Wendling

      I found it so weird I just tested in a VM, and it worked just fine under Xubuntu 14.04.1. So… I don't know what to tell you.

      Maybe, what does pkg-config --cflags vte give you? (should output a bunch of C compiler flags if it works)

       
  • Ron Brash

    Ron Brash - 2015-02-09

    pkg-config --cflags vte
    -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/vte-0.0

    So it is the last listed there, but for whatever reason autotools/pkgconfig didn't find it.

     
    • Colomban Wendling

      Hum… did you happen to install libvte-dev after running configure by any chance?

      Anyway, to debug that could you attach your config.log?

       
  • Ron Brash

    Ron Brash - 2015-02-12

    No it was installed previously, but that system is now MIA; It appears to be working now though on a fresh install.

    Perhaps autotool should check for the existence of libdev-vte and bail if not found?

     
    • Colomban Wendling

      It disables the plugin if not found. This said, when the plugin is disabled it only prevents automatic recursion in its folder, I think you can still trick it into trying to build by running make directly from the plugin's subdirectory.