[Terminal] crash on close/quit

[karmak]

After having done many operation in a Terminal (notably, a tar -xzvf /boot which produced huge output and slowed down the system, and a scp which failed with a no buffer space available error), I closed it with Control-D (it was my last Terminal open), and got this crash :

#0  0xffff0104 in ?? ()
#1  0x006cae8e in debugger () from /boot/beos/system/lib/libroot.so
#2  0x006d4551 in __assert_fail () from /boot/beos/system/lib/libroot.so
#3  0x006dd456 in BPrivate::hoardHeap::freeBlock ()
   from /boot/beos/system/lib/libroot.so
#4  0x006de4e9 in BPrivate::processHeap::free ()
   from /boot/beos/system/lib/libroot.so
#5  0x006dfc2b in free () from /boot/beos/system/lib/libroot.so
#6  0x0021882f in BasicTerminalBuffer::_FreeLines ()
#7  0x00216cf5 in BasicTerminalBuffer::~BasicTerminalBuffer ()
#8  0x002213f5 in TerminalBuffer::~TerminalBuffer ()
#9  0x00224a20 in TermView::~TermView ()
#10 0x002309e7 in CustomTermView::~CustomTermView ()
#11 0x003924db in BView::~BView () from /boot/beos/system/lib/libbe.so
#12 0x00230a5b in TermViewContainerView::~TermViewContainerView ()
#13 0x003924db in BView::~BView () from /boot/beos/system/lib/libbe.so
#14 0x00367fc8 in BScrollView::~BScrollView ()
   from /boot/beos/system/lib/libbe.so
#15 0x00223a18 in TermScrollView::~TermScrollView ()
#16 0x0037c890 in BTab::~BTab () from /boot/beos/system/lib/libbe.so
#17 0x0037d4e8 in BTabView::~BTabView () from /boot/beos/system/lib/libbe.so
#18 0x0021f128 in SmartTabView::~SmartTabView ()
#19 0x00230b2f in TermWindow::TabView::~TabView ()
#20 0x003924db in BView::~BView () from /boot/beos/system/lib/libbe.so
#21 0x0039e456 in BWindow::~BWindow () from /boot/beos/system/lib/libbe.so
#22 0x0022c452 in TermWindow::~TermWindow ()
#23 0x002f5065 in BLooper::Quit () from /boot/beos/system/lib/libbe.so
#24 0x0039eba9 in BWindow::Quit () from /boot/beos/system/lib/libbe.so
#25 0x002f667c in BLooper::_QuitRequested ()
   from /boot/beos/system/lib/libbe.so
#26 0x002f4bf4 in BLooper::DispatchMessage ()
   from /boot/beos/system/lib/libbe.so
#27 0x003a153a in BWindow::DispatchMessage ()
   from /boot/beos/system/lib/libbe.so
#28 0x003a4e7f in BWindow::task_looper () from /boot/beos/system/lib/libbe.so
#29 0x002f60ff in BLooper::_task0_ () from /boot/beos/system/lib/libbe.so
#30 0x006cf640 in thread_entry () from /boot/beos/system/lib/libroot.so
#31 0x700c1fec in ?? ()

I entered cont, and got the following (probably harmless, but in case not I put it here) :

#0  0xffff0104 in ?? ()
#1  0x006cf7db in wait_for_thread () from /boot/beos/system/lib/libroot.so
#2  0x002f50aa in BLooper::Quit () from /boot/beos/system/lib/libbe.so
#3  0x0039eba9 in BWindow::Quit () from /boot/beos/system/lib/libbe.so
#4  0x002ecf20 in BApplication::_WindowQuitLoop ()
   from /boot/beos/system/lib/libbe.so
#5  0x002ecf8f in BApplication::_QuitAllWindows ()
   from /boot/beos/system/lib/libbe.so
#6  0x002ea425 in BApplication::QuitRequested ()
   from /boot/beos/system/lib/libbe.so
#7  0x002f65ac in BLooper::_QuitRequested ()
   from /boot/beos/system/lib/libbe.so
#8  0x002f4bf4 in BLooper::DispatchMessage ()
   from /boot/beos/system/lib/libbe.so
#9  0x002ebad5 in BApplication::DispatchMessage ()
   from /boot/beos/system/lib/libbe.so
#10 0x002f6505 in BLooper::task_looper () from /boot/beos/system/lib/libbe.so
#11 0x002ea2de in BApplication::Run () from /boot/beos/system/lib/libbe.so
#12 0x0021bf8f in main ()

My knowledge is currently limited, i'm (re-)learning how to inspect backtraces, variables and other debug things ; I've not done these things for years (since I programmed DeeperPeople for BeOS in 2001, to be exact).

[axeld]

This could be a memory shortage related bug in the terminal buffer implementation.

[bonefish]

Replying to axeld:

This could be a memory shortage related bug in the terminal buffer implementation.

The terminal buffer implementation is one of the few places in the terminal code that does deal with failed memory allocations. Besides, unless you resize the terminal it doesn't need to do anymore allocations.

Anyway, an assert in the memory allocator could be caused by double frees or overwritten memory. Impossible to pinpoint from just the back trace.

@karmak: Among the stuff gdb initially prints there's at least one interesting line giving the reason for entering the debugger. Usually something like "Thread ... caused an exception:..." or "Thread ... called debugger:...". Please always also give this line in a bug report (in doubt copy the whole output).

[bonefish]

In 2009 several patches by Joshua R. Elsasser have been applied that fixed potential memory corruption bugs. Closing the ticket as potentially fixed. Without an at least somewhat reproducible test case there's little that can be done with it anyway.