Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

How to solve this Segmentation fault?

Programming languages, Coding, Executables, Package Creation, and Scripting.
Post Reply
Message
Author
hack3rcon
Posts: 746
Joined: 2015-02-16 09:54
Has thanked: 48 times

How to solve this Segmentation fault?

#1 Post by hack3rcon »

Hello,
I want to run "Ramme" (https://github.com/terkelg/ramme) program, but it show me "Segmentation fault" error and program can't run.
I tried "gdb" to find a solution of this problem, but tutorials that I found on the Internet was about small programs with source codes. GDB show me:

Code: Select all

(gdb) run
Starting program: /usr/local/bin/ramme 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000e6e0c0 in ?? ()
(gdb) backtrace 
#0  0x0000000000e6e0c0 in ?? ()
#1  0x00007ffff7d85462 in node::http2::Http2Session::Callbacks::Callbacks(bool)
    () from /opt/Ramme/libnode.so
#2  0x00007ffff7d85525 in ?? () from /opt/Ramme/libnode.so
#3  0x00007ffff7fe437a in call_init (l=<optimized out>, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffe278, env=env@entry=0x7fffffffe288)
    at dl-init.c:72
#4  0x00007ffff7fe4476 in call_init (env=0x7fffffffe288, argv=0x7fffffffe278, 
    argc=1, l=<optimized out>) at dl-init.c:30
#5  _dl_init (main_map=0x7ffff7ffe190, argc=1, argv=0x7fffffffe278, 
    env=0x7fffffffe288) at dl-init.c:119
#6  0x00007ffff7fd60ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#7  0x0000000000000001 in ?? ()
#8  0x00007fffffffe549 in ?? ()
#9  0x0000000000000000 in ?? ()
(gdb) where
#0  0x0000000000e6e0c0 in ?? ()
#1  0x00007ffff7d85462 in node::http2::Http2Session::Callbacks::Callbacks(bool) () from /opt/Ramme/libnode.so
#2  0x00007ffff7d85525 in ?? () from /opt/Ramme/libnode.so
#3  0x00007ffff7fe437a in call_init (l=<optimized out>, argc=argc@entry=2, argv=argv@entry=0x7fffffffe258, 
    env=env@entry=0x7fffffffe270) at dl-init.c:72
#4  0x00007ffff7fe4476 in call_init (env=0x7fffffffe270, argv=0x7fffffffe258, argc=2, l=<optimized out>)
    at dl-init.c:30
#5  _dl_init (main_map=0x7ffff7ffe190, argc=2, argv=0x7fffffffe258, env=0x7fffffffe270) at dl-init.c:119
#6  0x00007ffff7fd60ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#7  0x0000000000000002 in ?? ()
#8  0x00007fffffffe53e in ?? ()
#9  0x00007fffffffe553 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb) list
1	../sysdeps/x86/dl-procinfo.c: No such file or directory.
(gdb) print 0x0000000000e6e0c0
$4 = 15130816
(gdb) print 0x00007ffff7d85462
$5 = 140737351537762
(gdb) print 0x00007ffff7d85525
$6 = 140737351537957
(gdb) print 0x00007ffff7fe437a
$7 = 140737354023802
(gdb) pt
type = long
I used "Valgrind" and it show me:

Code: Select all

$ valgrind --leak-check=full ramme
==2150== Memcheck, a memory error detector
==2150== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2150== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2150== Command: ramme
==2150== 
==2150== 
==2150== Process terminating with default action of signal 11 (SIGSEGV)
==2150==  Bad permissions for mapped region at address 0xE6E0C0
==2150==    at 0xE6E0C0: ??? (in /opt/Ramme/ramme)
==2150==    by 0x70FB461: node::http2::Http2Session::Callbacks::Callbacks(bool) (in /opt/Ramme/libnode.so)
==2150==    by 0x70FB524: ??? (in /opt/Ramme/libnode.so)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== HEAP SUMMARY:
==2150==     in use at exit: 136,047 bytes in 896 blocks
==2150==   total heap usage: 1,512 allocs, 616 frees, 227,691 bytes allocated
==2150== 
==2150== 16 bytes in 1 blocks are possibly lost in loss record 90 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28DF6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C038: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0B04E: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049A7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 16 bytes in 1 blocks are possibly lost in loss record 91 of 262
==2150==    at 0x60656AF: malloc (vg_replace_malloc.c:298)
==2150==    by 0x6067DE7: realloc (vg_replace_malloc.c:826)
==2150==    by 0x8FFE96B: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28CE8: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C038: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0B04E: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049A7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 16 bytes in 1 blocks are possibly lost in loss record 92 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28DF6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C038: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0B0B1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049A7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 16 bytes in 1 blocks are possibly lost in loss record 93 of 262
==2150==    at 0x60656AF: malloc (vg_replace_malloc.c:298)
==2150==    by 0x6067DE7: realloc (vg_replace_malloc.c:826)
==2150==    by 0x8FFE96B: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28CE8: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C038: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0B0B1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049A7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 16 bytes in 1 blocks are possibly lost in loss record 94 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28DF6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C038: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F14F9B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049B1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 16 bytes in 1 blocks are possibly lost in loss record 95 of 262
==2150==    at 0x60656AF: malloc (vg_replace_malloc.c:298)
==2150==    by 0x6067DE7: realloc (vg_replace_malloc.c:826)
==2150==    by 0x8FFE96B: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28CE8: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C038: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F14F9B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049B1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 16 bytes in 1 blocks are possibly lost in loss record 96 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28DF6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C038: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0FE1B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049B6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 16 bytes in 1 blocks are possibly lost in loss record 97 of 262
==2150==    at 0x60656AF: malloc (vg_replace_malloc.c:298)
==2150==    by 0x6067DE7: realloc (vg_replace_malloc.c:826)
==2150==    by 0x8FFE96B: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28CE8: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C038: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0FE1B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049B6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 96 bytes in 1 blocks are possibly lost in loss record 231 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F282EA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F048CA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 96 bytes in 1 blocks are possibly lost in loss record 232 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F282EA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C02A: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0B04E: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049A7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 96 bytes in 1 blocks are possibly lost in loss record 233 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F282EA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C02A: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0B0B1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049A7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 96 bytes in 1 blocks are possibly lost in loss record 234 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F282EA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C02A: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F14F9B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049B1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 96 bytes in 1 blocks are possibly lost in loss record 235 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F28151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F282EA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C02A: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0FE1B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049B6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 132 bytes in 1 blocks are possibly lost in loss record 238 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F29754: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C0B9: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0B04E: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049A7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 132 bytes in 1 blocks are possibly lost in loss record 239 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F29754: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C0B9: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0B0B1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049A7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 148 bytes in 1 blocks are possibly lost in loss record 240 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F29568: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C0B9: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F14F9B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049B1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 148 bytes in 1 blocks are possibly lost in loss record 241 of 262
==2150==    at 0x6067B65: calloc (vg_replace_malloc.c:752)
==2150==    by 0x8FFE918: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F29568: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C0B9: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F0FE1B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049B6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== 184 bytes in 1 blocks are possibly lost in loss record 244 of 262
==2150==    at 0x6067D7B: realloc (vg_replace_malloc.c:826)
==2150==    by 0x8FFE96B: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3)
==2150==    by 0x7F280CC: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F2C29C: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F16C80: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F1967A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x7F049BB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5800.3)
==2150==    by 0x583F379: call_init.part.0 (dl-init.c:72)
==2150==    by 0x583F475: call_init (dl-init.c:118)
==2150==    by 0x583F475: _dl_init (dl-init.c:119)
==2150==    by 0x58310C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.28.so)
==2150== 
==2150== LEAK SUMMARY:
==2150==    definitely lost: 0 bytes in 0 blocks
==2150==    indirectly lost: 0 bytes in 0 blocks
==2150==      possibly lost: 1,352 bytes in 18 blocks
==2150==    still reachable: 134,695 bytes in 878 blocks
==2150==                       of which reachable via heuristic:
==2150==                         stdstring          : 34 bytes in 1 blocks
==2150==                         newarray           : 1,536 bytes in 16 blocks
==2150==         suppressed: 0 bytes in 0 blocks
==2150== Reachable blocks (those to which a pointer was found) are not shown.
==2150== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2150== 
==2150== For counts of detected and suppressed errors, rerun with: -v
==2150== ERROR SUMMARY: 18 errors from 18 contexts (suppressed: 0 from 0)
Segmentation fault
How can I used "gdb" to solve it?

Thank you.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: How to solve this Segmentation fault?

#2 Post by Head_on_a_Stick »

Those stack traces aren't much use without the debugging symbols:

https://wiki.debian.org/HowToGetABacktrace
deadbang

hack3rcon
Posts: 746
Joined: 2015-02-16 09:54
Has thanked: 48 times

Re: How to solve this Segmentation fault?

#3 Post by hack3rcon »

Head_on_a_Stick wrote:Those stack traces aren't much use without the debugging symbols:

https://wiki.debian.org/HowToGetABacktrace
Thank you.
I did:

Code: Select all

$ find-dbgsym-packages /usr/local/bin/ramme
W: Cannot parse ldd output: '	libnode.so => not found'
W: Cannot parse ldd output: '	libffmpeg.so => not found'
W: No build-ID for /usr/local/bin/ramme
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXcomposite.so.1
W: Cannot find debug package for /lib/x86_64-linux-gnu/libXcomposite.so.1 (fd60c2c65acf6eaa3f92c2b9a12899e3ead42141)
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libp11-kit.so.0
W: Cannot find debug package for /lib/x86_64-linux-gnu/libp11-kit.so.0 (7b23874f495fc6224cfe5d00b0268f309a659301)
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXau.so.6
W: Cannot find debug package for /lib/x86_64-linux-gnu/libXau.so.6 (f48f35ab49693e957bf0b776a3669a8fc7d226e2)
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXext.so.6
W: Cannot find debug package for /lib/x86_64-linux-gnu/libXext.so.6 (2fcae7c9cf1b5ba62085611c360601b428ba24b9)
libasound2-dbgsym libatk-bridge2.0-0-dbgsym libatk1.0-0-dbgsym libatspi2.0-0-dbgsym libavahi-client3-dbgsym libavahi-common3-dbgsym libblkid1-dbgsym libbsd0-dbgsym libcairo-gobject2-dbgsym libcairo2-dbgsym libcom-err2-dbgsym libcups2-dbgsym libdatrie1-dbgsym libdbus-1-3-dbgsym libdbus-glib-1-2-dbgsym libepoxy0-dbgsym libexpat1-dbgsym libffi6-dbg libfontconfig1-dbgsym libfreetype6-dbgsym libfribidi0-dbgsym libgcc1-dbg libgconf-2-4-dbgsym libgcrypt20-dbgsym libgdk-pixbuf2.0-0-dbgsym libglib2.0-0-dbgsym libgmp10-dbgsym libgnutls30-dbgsym libgpg-error0-dbgsym libgraphite2-3-dbgsym libgtk-3-0-dbgsym libharfbuzz0b-dbgsym libhogweed4-dbgsym libidn2-0-dbgsym libkeyutils1-dbgsym libkrb5-dbg liblz4-1-dbgsym liblzma5-dbgsym libmount1-dbgsym libnettle6-dbgsym libnspr4-dbgsym libnss3-dbgsym libpango-1.0-0-dbgsym libpangocairo-1.0-0-dbgsym libpangoft2-1.0-0-dbgsym libpcre3-dbg libpixman-1-0-dbgsym libpng16-16-dbgsym libselinux1-dbgsym libstdc++6-8-dbg libsystemd0-dbgsym libtasn1-6-dbgsym libthai0-dbgsym libunistring2-dbgsym libuuid1-dbgsym libwayland-client0-dbgsym libwayland-cursor0-dbgsym libwayland-egl1-dbgsym libx11-6-dbgsym libx11-xcb1-dbgsym libxcb-render0-dbgsym libxcb-shm0-dbgsym libxcb1-dbgsym libxcursor1-dbgsym libxdamage1-dbgsym libxdmcp6-dbg libxfixes3-dbgsym libxi6-dbgsym libxinerama1-dbgsym libxkbcommon0-dbgsym libxrandr2-dbgsym libxrender1-dbgsym libxss1-dbgsym libxtst6-dbgsym zlib1g-dbg
What is your opinion?

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: How to solve this Segmentation fault?

#4 Post by Head_on_a_Stick »

hack3rcon wrote:What is your opinion?
You need to show us everything that you did to make the debugging packages available. What did you add to your sources? Did you update the package database afterwards? The more information you provide the better the answers you will receive.
deadbang

hack3rcon
Posts: 746
Joined: 2015-02-16 09:54
Has thanked: 48 times

Re: How to solve this Segmentation fault?

#5 Post by hack3rcon »

Head_on_a_Stick wrote:
hack3rcon wrote:What is your opinion?
You need to show us everything that you did to make the debugging packages available. What did you add to your sources? Did you update the package database afterwards? The more information you provide the better the answers you will receive.
I added below lines to my "sources.list" file:

Code: Select all

deb http://deb.debian.org/debian-debug/ buster-debug main
# for security updates
deb http://deb.debian.org/debian-debug/ buster-proposed-updates-debug main
Then:

Code: Select all

$ sudo apt-get update

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: How to solve this Segmentation fault?

#6 Post by Head_on_a_Stick »

Sorry, I didn't read your posts carefully enough.

The debug packages you need to install are indicated by the lines in the backtrace that contain "??", for example:
hack3rcon wrote:

Code: Select all

#2  0x00007ffff7d85525 in ?? () from /opt/Ramme/libnode.so
^ In that case the symbols are missing from /opt/Ramme/libnode.so but that is supplied by the program itself and so there is no debugging version available from Debian.

tl;dr: ask the Ramme developers to help you with this.
deadbang

hack3rcon
Posts: 746
Joined: 2015-02-16 09:54
Has thanked: 48 times

Re: How to solve this Segmentation fault?

#7 Post by hack3rcon »

Head_on_a_Stick wrote:Sorry, I didn't read your posts carefully enough.

The debug packages you need to install are indicated by the lines in the backtrace that contain "??", for example:
hack3rcon wrote:

Code: Select all

#2  0x00007ffff7d85525 in ?? () from /opt/Ramme/libnode.so
^ In that case the symbols are missing from /opt/Ramme/libnode.so but that is supplied by the program itself and so there is no debugging version available from Debian.

tl;dr: ask the Ramme developers to help you with this.
Thus, sometime a program can't debug?

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: How to solve this Segmentation fault?

#8 Post by Head_on_a_Stick »

You can't debug that program without the debugging symbols and those are not available from the Debian repositories. The Ramme developers may be able to tell you how to install the symbols for their package so you should ask them.
deadbang

hack3rcon
Posts: 746
Joined: 2015-02-16 09:54
Has thanked: 48 times

Re: How to solve this Segmentation fault?

#9 Post by hack3rcon »

Head_on_a_Stick wrote:You can't debug that program without the debugging symbols and those are not available from the Debian repositories. The Ramme developers may be able to tell you how to install the symbols for their package so you should ask them.
Thanks.

Post Reply