This is a spin-off from bug #46949 (framebuffer console restoration issue) comment 3.

Current FrameBuffer Gnash seems to always produce a segmentation fault on
its exit procedure, with backtrace more or less similar to:

#0  0x00000109 in ?? ()
#1  0xb7701096 in std::_Sp_counted_ptr<gnash::Renderer*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0xb90d5108) at /usr/include/c++/4.7/bits/shared_ptr_base.h:293
#2  0xb76d5a08 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0xb90d5108) at /usr/include/c++/4.7/bits/shared_ptr_base.h:147
#3  0xb76f730e in ~__shared_count (this=0xb90cb844, __in_chrg=<optimized out>) at /usr/include/c++/4.7/bits/shared_ptr_base.h:558
#4  ~__shared_ptr (this=0xb90cb840, __in_chrg=<optimized out>) at /usr/include/c++/4.7/bits/shared_ptr_base.h:813
#5  ~shared_ptr (this=0xb90cb840, __in_chrg=<optimized out>) at /usr/include/c++/4.7/bits/shared_ptr.h:93
#6  gnash::RunResources::~RunResources (this=0xb90cb828, __in_chrg=<optimized out>) at ../libcore/RunResources.h:53
#7  0xb76f73c9 in std::_Sp_counted_ptr<gnash::RunResources*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0xb90c9750) at /usr/include/c++/4.7/bits/shared_ptr_base.h:293
#8  0xb76d5a08 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0xb90c9750) at /usr/include/c++/4.7/bits/shared_ptr_base.h:147
#9  0xb76f39f7 in ~__shared_count (this=0xbff41f14, __in_chrg=<optimized out>) at /usr/include/c++/4.7/bits/shared_ptr_base.h:558
#10 ~__shared_ptr (this=0xbff41f10, __in_chrg=<optimized out>) at /usr/include/c++/4.7/bits/shared_ptr_base.h:813
#11 ~shared_ptr (this=0xbff41f10, __in_chrg=<optimized out>) at /usr/include/c++/4.7/bits/shared_ptr.h:93
#12 gnash::Player::~Player (this=0xbff41eb0, __in_chrg=<optimized out>) at Player.cpp:866
#13 0xb76cf328 in playFile (player=..., argc=4, argv=0xbff427c4, filename="...)" at gnash.cpp:92
#14 0xb76d5005 in __call<void, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, 0u, 1u, 2u, 3u> (__args=..., this=0xbff422d8) at /usr/include/c++/4.7/functional:1156
#15 operator()<std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, void> (this=0xbff422d8) at /usr/include/c++/4.7/functional:1215
#16 std::for_each<__gnu_cxx::__normal_iterator<std::string*, std::vector<std::string, std::allocator<std::string> > >, std::_Bind<void (*(std::reference_wrapper<gnash::Player>, int, char**, std::_Placeholder<1>))(gnash::Player&, int, char**, std::string const&)> >(__gnu_cxx::__normal_iterator<std::string*, std::vector<std::string, std::allocator<std::string> > >, __gnu_cxx::__normal_iterator<std::string*, std::vector<std::string, std::allocator<std::string> > >, std::_Bind<void (*(std::reference_wrapper<gnash::Player>, int, char**, std::_Placeholder<1>))(gnash::Player&, int, char**, std::string const&)>) (__first=..., __last=..., __f=...) at /usr/include/c++/4.7/bits/stl_algo.h:4442
#17 0xb76cdbaf in main (argc=4, argv=0xbff427c4) at gnash.cpp:176

The way Gnash exit doesn't seems to significantly change the backtrace. Tested with:

• `fscommand("quit")` ActionScript code when `set ignoreFSCommand` in `~/.gnashrc` is `false`
• `--once` command line option
• SIGINT (via Ctrl+C)
• and SIGTERM (via `killall`)

Log output and detailed GDB backtrace from running `singleframe.swf` (from
file #35320 in bug #46308) using `fb-gnash -vv --once singleframe.swf`
are also attached.

This issue is specific to Gnash's FrameBuffer UI.
GTK, Qt4, SDL, and Dump UI are not affected.

Gnash: 0.8.11dev (git e705394 29-Jan-2016)
Framebuffer: inteldrmfb `/dev/fb0` 1366x768 32-bit
System: Debian GNU/Linux 7.0 Wheezy i386