Using GDB to fix double free or corruption (!prev) error in large project












1















Background:



I have forked a rather large project (popcornmix omxplayer repo) and I am modifying it to allow for synchronization on multiple displays. I am getting the following segmentation fault at run time



*** Error in `./omxplayer.bin': double free or corruption (!prev): 0x02141400 ***
./omxplayer: line 67: 17399 Aborted (core dumped) LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"


Print statements proved completely useless. I am following the tutorials online (see links below) to use gdb to trace the exact location that the segmentation fault occurs but I find the the examples they give are trivial to the point of being a hello_world program which is not indicative of my issue. Similarly, questions asked on SO follow this same trend, where users post their code snippet here, and someone identifies the programming error (see below). When I run backtrace it redirects me to system files/C files (not sure about the terminology). Here is a sample output:



$ gdb omxplayer.bin core
GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 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 "arm-linux-gnueabihf".
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 omxplayer.bin...(no debugging symbols found)...done.
[New LWP 17417]
[New LWP 17412]
[New LWP 17399]
[New LWP 17416]
[New LWP 17409]
[New LWP 17413]
[New LWP 17411]
[New LWP 17408]
[New LWP 17415]
[New LWP 17410]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./omxplayer.bin --sync-server --server-port 1234 --sync-num-client 1 --sync-ver'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x6ef80340 (LWP 17417))]
(gdb) where
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x75a9c824 in __GI_abort () at abort.c:89
#2 0x00083dc0 in sig_handler(int) ()
#3 <signal handler called>
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5 0x75a9c824 in __GI_abort () at abort.c:89
#6 0x75ad5f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:175
#7 0x75adcad4 in malloc_printerr (action=<optimized out>,
str=0x75b8ef70 "double free or corruption (!prev)", ptr=<optimized out>,
ar_ptr=<optimized out>) at malloc.c:5049
#8 0x75add514 in _int_free (av=0x75bab794 <main_arena>, p=0x21413f8,
have_lock=<optimized out>) at malloc.c:3905
#9 0x00038260 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb)
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) backtrace
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x75a9c824 in __GI_abort () at abort.c:89
#2 0x00083dc0 in sig_handler(int) ()
#3 <signal handler called>
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5 0x75a9c824 in __GI_abort () at abort.c:89
#6 0x75ad5f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:175
#7 0x75adcad4 in malloc_printerr (action=<optimized out>,
str=0x75b8ef70 "double free or corruption (!prev)", ptr=<optimized out>,
ar_ptr=<optimized out>) at malloc.c:5049
#8 0x75add514 in _int_free (av=0x75bab794 <main_arena>, p=0x21413f8,
have_lock=<optimized out>) at malloc.c:3905
#9 0x00038260 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


I was hoping to get comments like omxplayer.cpp line 123: int *foo but instead it tells me the error is occuring in malloc.c which is not entirely useful.



Question: Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?



Some GDB tutorials:




  1. How to correctly compile

  2. Using Core files (see Robie Basak's comment)

  3. Disabling Randomization

  4. Back Tracing


Trivial SO Questions:




  1. double free or corruption (!prev)


  2. Double free or corruption (!prev) error in C


  3. Error in `./a.out': double free or corruption (!prev): 0x0000000000bb0470











share|improve this question


















  • 2





    Seems to me like using valgrind should prove much simpler

    – StoryTeller
    Jan 18 at 18:58











  • @StoryTeller It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises (see valgrind.org/docs/manual/mc-manual.html, 4.2.4)

    – puk
    Jan 18 at 19:15













  • @puk But wouldn't it allow you to narrow down the kind of problem, i.e. corruption or double free ? And wouldn't the execution tree help you to locate the problem easier than with GDB ?

    – Christophe
    Jan 18 at 20:00











  • @Christophe I am not a very good programmer, what I am looking for is breadcrumbs, or a trace saying something like entered main.cpp... called foo() at main.cpp line 123, call foo2() at foo.cpp line 456.... Thank you for the link. I will have a look at your execution tree link in the next 2-6 hours

    – puk
    Jan 18 at 20:07
















1















Background:



I have forked a rather large project (popcornmix omxplayer repo) and I am modifying it to allow for synchronization on multiple displays. I am getting the following segmentation fault at run time



*** Error in `./omxplayer.bin': double free or corruption (!prev): 0x02141400 ***
./omxplayer: line 67: 17399 Aborted (core dumped) LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"


Print statements proved completely useless. I am following the tutorials online (see links below) to use gdb to trace the exact location that the segmentation fault occurs but I find the the examples they give are trivial to the point of being a hello_world program which is not indicative of my issue. Similarly, questions asked on SO follow this same trend, where users post their code snippet here, and someone identifies the programming error (see below). When I run backtrace it redirects me to system files/C files (not sure about the terminology). Here is a sample output:



$ gdb omxplayer.bin core
GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 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 "arm-linux-gnueabihf".
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 omxplayer.bin...(no debugging symbols found)...done.
[New LWP 17417]
[New LWP 17412]
[New LWP 17399]
[New LWP 17416]
[New LWP 17409]
[New LWP 17413]
[New LWP 17411]
[New LWP 17408]
[New LWP 17415]
[New LWP 17410]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./omxplayer.bin --sync-server --server-port 1234 --sync-num-client 1 --sync-ver'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x6ef80340 (LWP 17417))]
(gdb) where
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x75a9c824 in __GI_abort () at abort.c:89
#2 0x00083dc0 in sig_handler(int) ()
#3 <signal handler called>
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5 0x75a9c824 in __GI_abort () at abort.c:89
#6 0x75ad5f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:175
#7 0x75adcad4 in malloc_printerr (action=<optimized out>,
str=0x75b8ef70 "double free or corruption (!prev)", ptr=<optimized out>,
ar_ptr=<optimized out>) at malloc.c:5049
#8 0x75add514 in _int_free (av=0x75bab794 <main_arena>, p=0x21413f8,
have_lock=<optimized out>) at malloc.c:3905
#9 0x00038260 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb)
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) backtrace
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x75a9c824 in __GI_abort () at abort.c:89
#2 0x00083dc0 in sig_handler(int) ()
#3 <signal handler called>
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5 0x75a9c824 in __GI_abort () at abort.c:89
#6 0x75ad5f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:175
#7 0x75adcad4 in malloc_printerr (action=<optimized out>,
str=0x75b8ef70 "double free or corruption (!prev)", ptr=<optimized out>,
ar_ptr=<optimized out>) at malloc.c:5049
#8 0x75add514 in _int_free (av=0x75bab794 <main_arena>, p=0x21413f8,
have_lock=<optimized out>) at malloc.c:3905
#9 0x00038260 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


I was hoping to get comments like omxplayer.cpp line 123: int *foo but instead it tells me the error is occuring in malloc.c which is not entirely useful.



Question: Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?



Some GDB tutorials:




  1. How to correctly compile

  2. Using Core files (see Robie Basak's comment)

  3. Disabling Randomization

  4. Back Tracing


Trivial SO Questions:




  1. double free or corruption (!prev)


  2. Double free or corruption (!prev) error in C


  3. Error in `./a.out': double free or corruption (!prev): 0x0000000000bb0470











share|improve this question


















  • 2





    Seems to me like using valgrind should prove much simpler

    – StoryTeller
    Jan 18 at 18:58











  • @StoryTeller It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises (see valgrind.org/docs/manual/mc-manual.html, 4.2.4)

    – puk
    Jan 18 at 19:15













  • @puk But wouldn't it allow you to narrow down the kind of problem, i.e. corruption or double free ? And wouldn't the execution tree help you to locate the problem easier than with GDB ?

    – Christophe
    Jan 18 at 20:00











  • @Christophe I am not a very good programmer, what I am looking for is breadcrumbs, or a trace saying something like entered main.cpp... called foo() at main.cpp line 123, call foo2() at foo.cpp line 456.... Thank you for the link. I will have a look at your execution tree link in the next 2-6 hours

    – puk
    Jan 18 at 20:07














1












1








1








Background:



I have forked a rather large project (popcornmix omxplayer repo) and I am modifying it to allow for synchronization on multiple displays. I am getting the following segmentation fault at run time



*** Error in `./omxplayer.bin': double free or corruption (!prev): 0x02141400 ***
./omxplayer: line 67: 17399 Aborted (core dumped) LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"


Print statements proved completely useless. I am following the tutorials online (see links below) to use gdb to trace the exact location that the segmentation fault occurs but I find the the examples they give are trivial to the point of being a hello_world program which is not indicative of my issue. Similarly, questions asked on SO follow this same trend, where users post their code snippet here, and someone identifies the programming error (see below). When I run backtrace it redirects me to system files/C files (not sure about the terminology). Here is a sample output:



$ gdb omxplayer.bin core
GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 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 "arm-linux-gnueabihf".
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 omxplayer.bin...(no debugging symbols found)...done.
[New LWP 17417]
[New LWP 17412]
[New LWP 17399]
[New LWP 17416]
[New LWP 17409]
[New LWP 17413]
[New LWP 17411]
[New LWP 17408]
[New LWP 17415]
[New LWP 17410]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./omxplayer.bin --sync-server --server-port 1234 --sync-num-client 1 --sync-ver'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x6ef80340 (LWP 17417))]
(gdb) where
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x75a9c824 in __GI_abort () at abort.c:89
#2 0x00083dc0 in sig_handler(int) ()
#3 <signal handler called>
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5 0x75a9c824 in __GI_abort () at abort.c:89
#6 0x75ad5f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:175
#7 0x75adcad4 in malloc_printerr (action=<optimized out>,
str=0x75b8ef70 "double free or corruption (!prev)", ptr=<optimized out>,
ar_ptr=<optimized out>) at malloc.c:5049
#8 0x75add514 in _int_free (av=0x75bab794 <main_arena>, p=0x21413f8,
have_lock=<optimized out>) at malloc.c:3905
#9 0x00038260 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb)
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) backtrace
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x75a9c824 in __GI_abort () at abort.c:89
#2 0x00083dc0 in sig_handler(int) ()
#3 <signal handler called>
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5 0x75a9c824 in __GI_abort () at abort.c:89
#6 0x75ad5f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:175
#7 0x75adcad4 in malloc_printerr (action=<optimized out>,
str=0x75b8ef70 "double free or corruption (!prev)", ptr=<optimized out>,
ar_ptr=<optimized out>) at malloc.c:5049
#8 0x75add514 in _int_free (av=0x75bab794 <main_arena>, p=0x21413f8,
have_lock=<optimized out>) at malloc.c:3905
#9 0x00038260 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


I was hoping to get comments like omxplayer.cpp line 123: int *foo but instead it tells me the error is occuring in malloc.c which is not entirely useful.



Question: Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?



Some GDB tutorials:




  1. How to correctly compile

  2. Using Core files (see Robie Basak's comment)

  3. Disabling Randomization

  4. Back Tracing


Trivial SO Questions:




  1. double free or corruption (!prev)


  2. Double free or corruption (!prev) error in C


  3. Error in `./a.out': double free or corruption (!prev): 0x0000000000bb0470











share|improve this question














Background:



I have forked a rather large project (popcornmix omxplayer repo) and I am modifying it to allow for synchronization on multiple displays. I am getting the following segmentation fault at run time



*** Error in `./omxplayer.bin': double free or corruption (!prev): 0x02141400 ***
./omxplayer: line 67: 17399 Aborted (core dumped) LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"


Print statements proved completely useless. I am following the tutorials online (see links below) to use gdb to trace the exact location that the segmentation fault occurs but I find the the examples they give are trivial to the point of being a hello_world program which is not indicative of my issue. Similarly, questions asked on SO follow this same trend, where users post their code snippet here, and someone identifies the programming error (see below). When I run backtrace it redirects me to system files/C files (not sure about the terminology). Here is a sample output:



$ gdb omxplayer.bin core
GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 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 "arm-linux-gnueabihf".
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 omxplayer.bin...(no debugging symbols found)...done.
[New LWP 17417]
[New LWP 17412]
[New LWP 17399]
[New LWP 17416]
[New LWP 17409]
[New LWP 17413]
[New LWP 17411]
[New LWP 17408]
[New LWP 17415]
[New LWP 17410]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./omxplayer.bin --sync-server --server-port 1234 --sync-num-client 1 --sync-ver'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x6ef80340 (LWP 17417))]
(gdb) where
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x75a9c824 in __GI_abort () at abort.c:89
#2 0x00083dc0 in sig_handler(int) ()
#3 <signal handler called>
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5 0x75a9c824 in __GI_abort () at abort.c:89
#6 0x75ad5f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:175
#7 0x75adcad4 in malloc_printerr (action=<optimized out>,
str=0x75b8ef70 "double free or corruption (!prev)", ptr=<optimized out>,
ar_ptr=<optimized out>) at malloc.c:5049
#8 0x75add514 in _int_free (av=0x75bab794 <main_arena>, p=0x21413f8,
have_lock=<optimized out>) at malloc.c:3905
#9 0x00038260 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb)
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) backtrace
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x75a9c824 in __GI_abort () at abort.c:89
#2 0x00083dc0 in sig_handler(int) ()
#3 <signal handler called>
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5 0x75a9c824 in __GI_abort () at abort.c:89
#6 0x75ad5f78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:175
#7 0x75adcad4 in malloc_printerr (action=<optimized out>,
str=0x75b8ef70 "double free or corruption (!prev)", ptr=<optimized out>,
ar_ptr=<optimized out>) at malloc.c:5049
#8 0x75add514 in _int_free (av=0x75bab794 <main_arena>, p=0x21413f8,
have_lock=<optimized out>) at malloc.c:3905
#9 0x00038260 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


I was hoping to get comments like omxplayer.cpp line 123: int *foo but instead it tells me the error is occuring in malloc.c which is not entirely useful.



Question: Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?



Some GDB tutorials:




  1. How to correctly compile

  2. Using Core files (see Robie Basak's comment)

  3. Disabling Randomization

  4. Back Tracing


Trivial SO Questions:




  1. double free or corruption (!prev)


  2. Double free or corruption (!prev) error in C


  3. Error in `./a.out': double free or corruption (!prev): 0x0000000000bb0470








c++ segmentation-fault gdb malloc






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 18 at 18:56









pukpuk

7,9112282155




7,9112282155








  • 2





    Seems to me like using valgrind should prove much simpler

    – StoryTeller
    Jan 18 at 18:58











  • @StoryTeller It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises (see valgrind.org/docs/manual/mc-manual.html, 4.2.4)

    – puk
    Jan 18 at 19:15













  • @puk But wouldn't it allow you to narrow down the kind of problem, i.e. corruption or double free ? And wouldn't the execution tree help you to locate the problem easier than with GDB ?

    – Christophe
    Jan 18 at 20:00











  • @Christophe I am not a very good programmer, what I am looking for is breadcrumbs, or a trace saying something like entered main.cpp... called foo() at main.cpp line 123, call foo2() at foo.cpp line 456.... Thank you for the link. I will have a look at your execution tree link in the next 2-6 hours

    – puk
    Jan 18 at 20:07














  • 2





    Seems to me like using valgrind should prove much simpler

    – StoryTeller
    Jan 18 at 18:58











  • @StoryTeller It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises (see valgrind.org/docs/manual/mc-manual.html, 4.2.4)

    – puk
    Jan 18 at 19:15













  • @puk But wouldn't it allow you to narrow down the kind of problem, i.e. corruption or double free ? And wouldn't the execution tree help you to locate the problem easier than with GDB ?

    – Christophe
    Jan 18 at 20:00











  • @Christophe I am not a very good programmer, what I am looking for is breadcrumbs, or a trace saying something like entered main.cpp... called foo() at main.cpp line 123, call foo2() at foo.cpp line 456.... Thank you for the link. I will have a look at your execution tree link in the next 2-6 hours

    – puk
    Jan 18 at 20:07








2




2





Seems to me like using valgrind should prove much simpler

– StoryTeller
Jan 18 at 18:58





Seems to me like using valgrind should prove much simpler

– StoryTeller
Jan 18 at 18:58













@StoryTeller It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises (see valgrind.org/docs/manual/mc-manual.html, 4.2.4)

– puk
Jan 18 at 19:15







@StoryTeller It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises (see valgrind.org/docs/manual/mc-manual.html, 4.2.4)

– puk
Jan 18 at 19:15















@puk But wouldn't it allow you to narrow down the kind of problem, i.e. corruption or double free ? And wouldn't the execution tree help you to locate the problem easier than with GDB ?

– Christophe
Jan 18 at 20:00





@puk But wouldn't it allow you to narrow down the kind of problem, i.e. corruption or double free ? And wouldn't the execution tree help you to locate the problem easier than with GDB ?

– Christophe
Jan 18 at 20:00













@Christophe I am not a very good programmer, what I am looking for is breadcrumbs, or a trace saying something like entered main.cpp... called foo() at main.cpp line 123, call foo2() at foo.cpp line 456.... Thank you for the link. I will have a look at your execution tree link in the next 2-6 hours

– puk
Jan 18 at 20:07





@Christophe I am not a very good programmer, what I am looking for is breadcrumbs, or a trace saying something like entered main.cpp... called foo() at main.cpp line 123, call foo2() at foo.cpp line 456.... Thank you for the link. I will have a look at your execution tree link in the next 2-6 hours

– puk
Jan 18 at 20:07












1 Answer
1






active

oldest

votes


















3















Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?




Yes: Valgrind and AddressSanitizer greatly help with finding the root cause of heap corruption errors.




It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises




That is incorrect. Valgrind (and AddressSanitizer) tell you exactly where the problem is. For a double-free, they tell you where the first free has happened earlier, and where the second free is happening now (and where the block was originally allocated).



Here is a sampe report from address sanitizer for a program that exhibits double-free:



#include <malloc.h>

int use_and_free(int *p)
{
int result = *p;
free(p);
}

int main(void)
{
const int num_pointers = 2;
int *p[num_pointers];

for (int j = 0; j < num_pointers; j++) {
p[j] = malloc(sizeof(int));
*p[j] = j;
}

int sum = 0;
for (int j = 0; j < num_pointers; j++) {
sum += use_and_free(p[j]);
}

// Oops: double-free.
free(p[0]);

return sum;
}

gcc -g t.c -fsanitize=address && ./a.out

=================================================================
==132174==ERROR: AddressSanitizer: attempting double-free on 0x602000000010 in thread T0:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c1ba9 in main /tmp/t.c:25
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#3 0x5654448c18a9 in _start (/tmp/a.out+0x8a9)

0x602000000010 is located 0 bytes inside of 4-byte region [0x602000000010,0x602000000014)
freed by thread T0 here:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c19e1 in use_and_free /tmp/t.c:6
#2 0x5654448c1b6a in main /tmp/t.c:21
#3 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

previously allocated by thread T0 here:
#0 0x7fa305b69c20 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9c20)
#1 0x5654448c1a77 in main /tmp/t.c:15
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: double-free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8) in __interceptor_free
==132174==ABORTING


You can clearly see 1) where the error is happening 2) where the problem block has been freed; and 3) where it was originally allocated.



Here is Valgrind output for the same program:



==132339== Invalid free() / delete / delete / realloc()
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1087B1: main (t.c:25)
==132339== Address 0x51d7040 is 0 bytes inside a block of size 4 free'd
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1086AA: use_and_free (t.c:6)
==132339== by 0x108793: main (t.c:21)


Above, you see the 1) and 2).






share|improve this answer


























  • When you say exactly where the problem is, do you mean at memory address 0xFF08d9... or in omxplayer.cpp line 123?

    – puk
    Jan 18 at 20:59











  • @puk I've updated the answer (but there is no reason you couldn't just see this for yourself).

    – Employed Russian
    Jan 18 at 21:55






  • 1





    +1 for pointing out that valgrind is the way to go. And for adding the info about AddressSanitiizer which I had not been aware of as of yet. Last not least, running a static code checker might also be a good idea, if it is a logical error, rather than some threading concurrency problem.

    – BitTickler
    Jan 18 at 22:40











  • Can you show how you are running Valgrind to get that output as I am getting something vastly different. Also, I think it might have to do with the -fsanitize=address flag. I am having difficulty getting it to work on raspian

    – puk
    Jan 19 at 0:33











  • @puk I am just running valgrind ./a.out. But on a Linux/x86_64 system. Your first step is try to replicate my output on a normal desktop. If Valgrind produces something different on raspian, you should ask a separate question about that.

    – Employed Russian
    Jan 19 at 0:51











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54259933%2fusing-gdb-to-fix-double-free-or-corruption-prev-error-in-large-project%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3















Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?




Yes: Valgrind and AddressSanitizer greatly help with finding the root cause of heap corruption errors.




It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises




That is incorrect. Valgrind (and AddressSanitizer) tell you exactly where the problem is. For a double-free, they tell you where the first free has happened earlier, and where the second free is happening now (and where the block was originally allocated).



Here is a sampe report from address sanitizer for a program that exhibits double-free:



#include <malloc.h>

int use_and_free(int *p)
{
int result = *p;
free(p);
}

int main(void)
{
const int num_pointers = 2;
int *p[num_pointers];

for (int j = 0; j < num_pointers; j++) {
p[j] = malloc(sizeof(int));
*p[j] = j;
}

int sum = 0;
for (int j = 0; j < num_pointers; j++) {
sum += use_and_free(p[j]);
}

// Oops: double-free.
free(p[0]);

return sum;
}

gcc -g t.c -fsanitize=address && ./a.out

=================================================================
==132174==ERROR: AddressSanitizer: attempting double-free on 0x602000000010 in thread T0:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c1ba9 in main /tmp/t.c:25
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#3 0x5654448c18a9 in _start (/tmp/a.out+0x8a9)

0x602000000010 is located 0 bytes inside of 4-byte region [0x602000000010,0x602000000014)
freed by thread T0 here:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c19e1 in use_and_free /tmp/t.c:6
#2 0x5654448c1b6a in main /tmp/t.c:21
#3 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

previously allocated by thread T0 here:
#0 0x7fa305b69c20 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9c20)
#1 0x5654448c1a77 in main /tmp/t.c:15
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: double-free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8) in __interceptor_free
==132174==ABORTING


You can clearly see 1) where the error is happening 2) where the problem block has been freed; and 3) where it was originally allocated.



Here is Valgrind output for the same program:



==132339== Invalid free() / delete / delete / realloc()
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1087B1: main (t.c:25)
==132339== Address 0x51d7040 is 0 bytes inside a block of size 4 free'd
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1086AA: use_and_free (t.c:6)
==132339== by 0x108793: main (t.c:21)


Above, you see the 1) and 2).






share|improve this answer


























  • When you say exactly where the problem is, do you mean at memory address 0xFF08d9... or in omxplayer.cpp line 123?

    – puk
    Jan 18 at 20:59











  • @puk I've updated the answer (but there is no reason you couldn't just see this for yourself).

    – Employed Russian
    Jan 18 at 21:55






  • 1





    +1 for pointing out that valgrind is the way to go. And for adding the info about AddressSanitiizer which I had not been aware of as of yet. Last not least, running a static code checker might also be a good idea, if it is a logical error, rather than some threading concurrency problem.

    – BitTickler
    Jan 18 at 22:40











  • Can you show how you are running Valgrind to get that output as I am getting something vastly different. Also, I think it might have to do with the -fsanitize=address flag. I am having difficulty getting it to work on raspian

    – puk
    Jan 19 at 0:33











  • @puk I am just running valgrind ./a.out. But on a Linux/x86_64 system. Your first step is try to replicate my output on a normal desktop. If Valgrind produces something different on raspian, you should ask a separate question about that.

    – Employed Russian
    Jan 19 at 0:51
















3















Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?




Yes: Valgrind and AddressSanitizer greatly help with finding the root cause of heap corruption errors.




It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises




That is incorrect. Valgrind (and AddressSanitizer) tell you exactly where the problem is. For a double-free, they tell you where the first free has happened earlier, and where the second free is happening now (and where the block was originally allocated).



Here is a sampe report from address sanitizer for a program that exhibits double-free:



#include <malloc.h>

int use_and_free(int *p)
{
int result = *p;
free(p);
}

int main(void)
{
const int num_pointers = 2;
int *p[num_pointers];

for (int j = 0; j < num_pointers; j++) {
p[j] = malloc(sizeof(int));
*p[j] = j;
}

int sum = 0;
for (int j = 0; j < num_pointers; j++) {
sum += use_and_free(p[j]);
}

// Oops: double-free.
free(p[0]);

return sum;
}

gcc -g t.c -fsanitize=address && ./a.out

=================================================================
==132174==ERROR: AddressSanitizer: attempting double-free on 0x602000000010 in thread T0:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c1ba9 in main /tmp/t.c:25
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#3 0x5654448c18a9 in _start (/tmp/a.out+0x8a9)

0x602000000010 is located 0 bytes inside of 4-byte region [0x602000000010,0x602000000014)
freed by thread T0 here:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c19e1 in use_and_free /tmp/t.c:6
#2 0x5654448c1b6a in main /tmp/t.c:21
#3 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

previously allocated by thread T0 here:
#0 0x7fa305b69c20 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9c20)
#1 0x5654448c1a77 in main /tmp/t.c:15
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: double-free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8) in __interceptor_free
==132174==ABORTING


You can clearly see 1) where the error is happening 2) where the problem block has been freed; and 3) where it was originally allocated.



Here is Valgrind output for the same program:



==132339== Invalid free() / delete / delete / realloc()
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1087B1: main (t.c:25)
==132339== Address 0x51d7040 is 0 bytes inside a block of size 4 free'd
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1086AA: use_and_free (t.c:6)
==132339== by 0x108793: main (t.c:21)


Above, you see the 1) and 2).






share|improve this answer


























  • When you say exactly where the problem is, do you mean at memory address 0xFF08d9... or in omxplayer.cpp line 123?

    – puk
    Jan 18 at 20:59











  • @puk I've updated the answer (but there is no reason you couldn't just see this for yourself).

    – Employed Russian
    Jan 18 at 21:55






  • 1





    +1 for pointing out that valgrind is the way to go. And for adding the info about AddressSanitiizer which I had not been aware of as of yet. Last not least, running a static code checker might also be a good idea, if it is a logical error, rather than some threading concurrency problem.

    – BitTickler
    Jan 18 at 22:40











  • Can you show how you are running Valgrind to get that output as I am getting something vastly different. Also, I think it might have to do with the -fsanitize=address flag. I am having difficulty getting it to work on raspian

    – puk
    Jan 19 at 0:33











  • @puk I am just running valgrind ./a.out. But on a Linux/x86_64 system. Your first step is try to replicate my output on a normal desktop. If Valgrind produces something different on raspian, you should ask a separate question about that.

    – Employed Russian
    Jan 19 at 0:51














3












3








3








Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?




Yes: Valgrind and AddressSanitizer greatly help with finding the root cause of heap corruption errors.




It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises




That is incorrect. Valgrind (and AddressSanitizer) tell you exactly where the problem is. For a double-free, they tell you where the first free has happened earlier, and where the second free is happening now (and where the block was originally allocated).



Here is a sampe report from address sanitizer for a program that exhibits double-free:



#include <malloc.h>

int use_and_free(int *p)
{
int result = *p;
free(p);
}

int main(void)
{
const int num_pointers = 2;
int *p[num_pointers];

for (int j = 0; j < num_pointers; j++) {
p[j] = malloc(sizeof(int));
*p[j] = j;
}

int sum = 0;
for (int j = 0; j < num_pointers; j++) {
sum += use_and_free(p[j]);
}

// Oops: double-free.
free(p[0]);

return sum;
}

gcc -g t.c -fsanitize=address && ./a.out

=================================================================
==132174==ERROR: AddressSanitizer: attempting double-free on 0x602000000010 in thread T0:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c1ba9 in main /tmp/t.c:25
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#3 0x5654448c18a9 in _start (/tmp/a.out+0x8a9)

0x602000000010 is located 0 bytes inside of 4-byte region [0x602000000010,0x602000000014)
freed by thread T0 here:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c19e1 in use_and_free /tmp/t.c:6
#2 0x5654448c1b6a in main /tmp/t.c:21
#3 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

previously allocated by thread T0 here:
#0 0x7fa305b69c20 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9c20)
#1 0x5654448c1a77 in main /tmp/t.c:15
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: double-free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8) in __interceptor_free
==132174==ABORTING


You can clearly see 1) where the error is happening 2) where the problem block has been freed; and 3) where it was originally allocated.



Here is Valgrind output for the same program:



==132339== Invalid free() / delete / delete / realloc()
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1087B1: main (t.c:25)
==132339== Address 0x51d7040 is 0 bytes inside a block of size 4 free'd
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1086AA: use_and_free (t.c:6)
==132339== by 0x108793: main (t.c:21)


Above, you see the 1) and 2).






share|improve this answer
















Is there a better way in gdb to find out exact where in the code the double free or corruption (!prev) error is arising?




Yes: Valgrind and AddressSanitizer greatly help with finding the root cause of heap corruption errors.




It seems Valgrind also only informs that a double free has occoured, but not where in your code this arises




That is incorrect. Valgrind (and AddressSanitizer) tell you exactly where the problem is. For a double-free, they tell you where the first free has happened earlier, and where the second free is happening now (and where the block was originally allocated).



Here is a sampe report from address sanitizer for a program that exhibits double-free:



#include <malloc.h>

int use_and_free(int *p)
{
int result = *p;
free(p);
}

int main(void)
{
const int num_pointers = 2;
int *p[num_pointers];

for (int j = 0; j < num_pointers; j++) {
p[j] = malloc(sizeof(int));
*p[j] = j;
}

int sum = 0;
for (int j = 0; j < num_pointers; j++) {
sum += use_and_free(p[j]);
}

// Oops: double-free.
free(p[0]);

return sum;
}

gcc -g t.c -fsanitize=address && ./a.out

=================================================================
==132174==ERROR: AddressSanitizer: attempting double-free on 0x602000000010 in thread T0:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c1ba9 in main /tmp/t.c:25
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#3 0x5654448c18a9 in _start (/tmp/a.out+0x8a9)

0x602000000010 is located 0 bytes inside of 4-byte region [0x602000000010,0x602000000014)
freed by thread T0 here:
#0 0x7fa305b698c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
#1 0x5654448c19e1 in use_and_free /tmp/t.c:6
#2 0x5654448c1b6a in main /tmp/t.c:21
#3 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

previously allocated by thread T0 here:
#0 0x7fa305b69c20 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9c20)
#1 0x5654448c1a77 in main /tmp/t.c:15
#2 0x7fa3057112b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: double-free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8) in __interceptor_free
==132174==ABORTING


You can clearly see 1) where the error is happening 2) where the problem block has been freed; and 3) where it was originally allocated.



Here is Valgrind output for the same program:



==132339== Invalid free() / delete / delete / realloc()
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1087B1: main (t.c:25)
==132339== Address 0x51d7040 is 0 bytes inside a block of size 4 free'd
==132339== at 0x4C2CD57: free (vg_replace_malloc.c:530)
==132339== by 0x1086AA: use_and_free (t.c:6)
==132339== by 0x108793: main (t.c:21)


Above, you see the 1) and 2).







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 18 at 23:38

























answered Jan 18 at 20:13









Employed RussianEmployed Russian

124k19165235




124k19165235













  • When you say exactly where the problem is, do you mean at memory address 0xFF08d9... or in omxplayer.cpp line 123?

    – puk
    Jan 18 at 20:59











  • @puk I've updated the answer (but there is no reason you couldn't just see this for yourself).

    – Employed Russian
    Jan 18 at 21:55






  • 1





    +1 for pointing out that valgrind is the way to go. And for adding the info about AddressSanitiizer which I had not been aware of as of yet. Last not least, running a static code checker might also be a good idea, if it is a logical error, rather than some threading concurrency problem.

    – BitTickler
    Jan 18 at 22:40











  • Can you show how you are running Valgrind to get that output as I am getting something vastly different. Also, I think it might have to do with the -fsanitize=address flag. I am having difficulty getting it to work on raspian

    – puk
    Jan 19 at 0:33











  • @puk I am just running valgrind ./a.out. But on a Linux/x86_64 system. Your first step is try to replicate my output on a normal desktop. If Valgrind produces something different on raspian, you should ask a separate question about that.

    – Employed Russian
    Jan 19 at 0:51



















  • When you say exactly where the problem is, do you mean at memory address 0xFF08d9... or in omxplayer.cpp line 123?

    – puk
    Jan 18 at 20:59











  • @puk I've updated the answer (but there is no reason you couldn't just see this for yourself).

    – Employed Russian
    Jan 18 at 21:55






  • 1





    +1 for pointing out that valgrind is the way to go. And for adding the info about AddressSanitiizer which I had not been aware of as of yet. Last not least, running a static code checker might also be a good idea, if it is a logical error, rather than some threading concurrency problem.

    – BitTickler
    Jan 18 at 22:40











  • Can you show how you are running Valgrind to get that output as I am getting something vastly different. Also, I think it might have to do with the -fsanitize=address flag. I am having difficulty getting it to work on raspian

    – puk
    Jan 19 at 0:33











  • @puk I am just running valgrind ./a.out. But on a Linux/x86_64 system. Your first step is try to replicate my output on a normal desktop. If Valgrind produces something different on raspian, you should ask a separate question about that.

    – Employed Russian
    Jan 19 at 0:51

















When you say exactly where the problem is, do you mean at memory address 0xFF08d9... or in omxplayer.cpp line 123?

– puk
Jan 18 at 20:59





When you say exactly where the problem is, do you mean at memory address 0xFF08d9... or in omxplayer.cpp line 123?

– puk
Jan 18 at 20:59













@puk I've updated the answer (but there is no reason you couldn't just see this for yourself).

– Employed Russian
Jan 18 at 21:55





@puk I've updated the answer (but there is no reason you couldn't just see this for yourself).

– Employed Russian
Jan 18 at 21:55




1




1





+1 for pointing out that valgrind is the way to go. And for adding the info about AddressSanitiizer which I had not been aware of as of yet. Last not least, running a static code checker might also be a good idea, if it is a logical error, rather than some threading concurrency problem.

– BitTickler
Jan 18 at 22:40





+1 for pointing out that valgrind is the way to go. And for adding the info about AddressSanitiizer which I had not been aware of as of yet. Last not least, running a static code checker might also be a good idea, if it is a logical error, rather than some threading concurrency problem.

– BitTickler
Jan 18 at 22:40













Can you show how you are running Valgrind to get that output as I am getting something vastly different. Also, I think it might have to do with the -fsanitize=address flag. I am having difficulty getting it to work on raspian

– puk
Jan 19 at 0:33





Can you show how you are running Valgrind to get that output as I am getting something vastly different. Also, I think it might have to do with the -fsanitize=address flag. I am having difficulty getting it to work on raspian

– puk
Jan 19 at 0:33













@puk I am just running valgrind ./a.out. But on a Linux/x86_64 system. Your first step is try to replicate my output on a normal desktop. If Valgrind produces something different on raspian, you should ask a separate question about that.

– Employed Russian
Jan 19 at 0:51





@puk I am just running valgrind ./a.out. But on a Linux/x86_64 system. Your first step is try to replicate my output on a normal desktop. If Valgrind produces something different on raspian, you should ask a separate question about that.

– Employed Russian
Jan 19 at 0:51


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54259933%2fusing-gdb-to-fix-double-free-or-corruption-prev-error-in-large-project%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Homophylophilia

Updating UILabel text programmatically using a function

Cloud Functions - OpenCV Videocapture Read method fails for larger files from cloud storage