Running melt in the debugger and waiting for it to
crash gives...
/lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xb7dd438a]
/lib/i386-linux-gnu/libc.so.6(+0x6dfc7)[0xb7ddafc7]
/lib/i386-linux-gnu/libc.so.6(+0x6e806)[0xb7ddb806]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x18)[0xb773da28]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev+0x25)[0xb77d9505]
/lib/i386-linux-gnu/libc.so.6(+0x2e7ab)[0xb7d9b7ab]
/lib/i386-linux-gnu/libc.so.6(+0x2e811)[0xb7d9b811]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0x102)[0xb7d85292]
/usr/bin/melt(+0x2d26)[0x80002d26]
Maybe the last line shows an informative offset
into melt. (0x80002d26).
I checked the package build log for code offsets.
http://clang.debian.net/logs/2017-08-20/mlt_6.4.1-5_unstable_clang.log
No luck.
Worse, it says 434 packages are required to
compile melt.
That looks hard.
So I tried something different: typing "bt", for "back trace".
It reported
(gdb) bt
#0 0xffffffff in __kernel_vsyscall ()
#1 0xffffffff in __GI_raise (set=0xbffff290) at
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2 0xffffffff in __GI_raise (sig=6) at
../sysdeps/unix/sysv/linux/raise.c:48
#3 0xffffffff in __GI_abort () at abort.c:89
#4 0xffffffff in __libc_message (do_abort=<optimized out>, fmt=<optimized
out>) at ../sysdeps/posix/libc_fatal.c:175
#5 0xffffffff in malloc_printerr (action=<optimized out>, str=0xb7ece35c
"double free or corruption (fasttop)", ptr=<optimized out>, ar_ptr=0xb7f20780
<main_arena>) at malloc.c:5049
#6 0xffffffff in _int_free (av=0xb7f20780 <main_arena>, p=0x801ad508,
have_lock=0) at malloc.c:3905
#7 0xffffffff in operator delete(void*) () at
/usr/lib/i386-linux-gnu/libstdc++.so.6
#8 0xffffffff in std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string() () at
/usr/lib/i386-linux-gnu/libstdc++.so.6
#9 0xffffffff in __run_exit_handlers (status=0, listp=0xb7f203dc
<__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:83
#10 0xffffffff in __GI_exit (status=0) at exit.c:105
#11 0xffffffff in __libc_start_main (main=0x80001960 <main>, argc=9,
argv=0xbffff854, init=0x80004160 <__libc_csu_init>, fini=0x800041c0
<__libc_csu_fini>, rtld_fini=0xb7feb070 <_dl_fini>, stack_end=0xbffff84c) at
../csu/libc-start.c:325
#12 0xffffffff in _start ()
Note: There's no "melt" or "mlt" in any stack
frame.
Frame number 9 mentions "atexit", which suggests
to me that glibc code is crashing when it tries to
execute a function specified in melt before it
exited.
That suggests to me melt's stack is gone.
And of no use.
If it weren't for bad luck, I'd have no luck at
all.
Certainly, valgrind will find the bug.
Next time: Or will it...?
So,
Kingsley
--
Time is the fire in which we all burn.
