Crash in WatchWindow::close_cur_view() after Pause

Bug #1553699 reported by Klaus Halfmann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Fix Released
Critical
Unassigned

Bug Description

* Open attached saved Game as Local Network game and switch to PAUSE
* Click near Barbarian Sentry at (31,50)
* Open "Watch field in a separate Window"
* Click "Follow"
* Click at Barbarian Sentry at (31,51)
* Open "Watch field in a separate Window"
* Click "Follow"
* Click at Barbarian Sentry at (31,51)
* Open "Watch field in a separate Window"
* Click "Follow"
* Click at Barbarian Fortress at (30,7)
* Open "Watch field in a separate Window"
* Click at Barbarian Tower at (27,15)
* Open "Watch field in a separate Window"
* Click at Barbarian Tower at (33,15) (This is Number 6!)
* Open "Watch field in a separate Window"
-- Wach field shows Tower at (33,15)
* UNPAUSE
* Press "Close" in Watch Window
! Will crash after closing #3 and while closing #2

As of Debugger crashes in

template <class _Tp, class _Up>
inline _LIBCPP_INLINE_VISIBILITY
typename enable_if
<
    is_same<typename remove_const<_Tp>::type, _Up>::value &&
    is_trivially_copy_assignable<_Up>::value,
    _Up*
>::type
__move(_Tp* __first, _Tp* __last, _Up* __result)
{
    const size_t __n = static_cast<size_t>(__last - __first);
    _VSTD::memmove(__result, __first, __n * sizeof(_Up)); --
    return __result + __n;
}

called from:

template <class _InputIterator, class _OutputIterator>
inline _LIBCPP_INLINE_VISIBILITY
_OutputIterator
move(_InputIterator __first, _InputIterator __last, _OutputIterator __result)
{
    return _VSTD::__move(__unwrap_iter(__first), __unwrap_iter(__last), __unwrap_iter(__result));
}

called from:

template <class _Tp, class _Allocator>
inline _LIBCPP_INLINE_VISIBILITY
typename vector<_Tp, _Allocator>::iterator
vector<_Tp, _Allocator>::erase(const_iterator __position)
{
#if _LIBCPP_DEBUG_LEVEL >= 2
    _LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__position) == this,
        "vector::erase(iterator) called with an iterator not"
        " referring to this vector");
#endif
    _LIBCPP_ASSERT(__position != end(),
        "vector::erase(iterator) called with a non-dereferenceable iterator");
    difference_type __ps = __position - cbegin();
    pointer __p = this->__begin_ + __ps;
    iterator __r = __make_iter(__p);
    this->__destruct_at_end(_VSTD::move(__p + 1, this->__end_, __p));
    return __r;
}

called from

void WatchWindow::close_cur_view()
{
 if (views.size() == 1) {
  die();
  return;
 }

 uint8_t const old_index = cur_index;
 next_view();
 std::vector<WatchWindowView>::iterator view_it = views.begin();
 for (uint8_t i = 0; i < old_index; ++i)
  ++view_it;
 view_btns[cur_index]->set_enabled(false);
 views.erase(view_it);
 toggle_buttons();
}

Version: bzr7866[trunk]
Compiled with clang on OSX

Tags: crash

Related branches

Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :
Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :
Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :
Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :

Looks like only the number of watche coordinates is the Problem,
not this mix of buildings, I now reproduces it with adjacent Sentries ony.
lets try again.

Ok hapens in own territoty as well. no need to un-pause.

GunChleoc (gunchleoc)
Changed in widelands:
milestone: none → build19-rc1
importance: Undecided → Critical
tags: added: crash
Revision history for this message
GunChleoc (gunchleoc) wrote :

I can't reproduce this on Ubuntu.

Revision history for this message
Miroslav Remák (miroslavr256) wrote :

I am not able to reproduce a crash on my system either, but I think I know where the problem lies. Can you
try these steps and see if they are enough to reproduce the issue:

1. Have at least 3 views in a watch window.
2. Select the next-to-last view and close it.
3. Click the close button again.

GunChleoc (gunchleoc)
Changed in widelands:
status: New → In Progress
Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :

Was able to reproduce this in bzr7903[trunk] in the way you described it. May be related to OSX / Clang Compiler.
Now trying again on bzr7904[watchwindow-fixes]

Changed in widelands:
status: In Progress → Fix Committed
Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :

Fixed in bzr7904[trunk]

Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :

Hello Gun: what else must be changed in the staus now?

Changed in widelands:
assignee: nobody → GunChleoc (gunchleoc)
status: Fix Committed → Fix Released
Revision history for this message
GunChleoc (gunchleoc) wrote :

When a fix is released, no need to assign people to the bug. Nothing else is needed :)

Changed in widelands:
assignee: GunChleoc (gunchleoc) → nobody
GunChleoc (gunchleoc)
Changed in widelands:
status: Fix Released → Fix Committed
GunChleoc (gunchleoc)
Changed in widelands:
status: Fix Committed → Fix Released
Revision history for this message
GunChleoc (gunchleoc) wrote :

Fixed in build19-rc1.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.