UFO: Alien Invasion Issue Tracker
Please log in to bookmark issues
OPEN  Bug report #2901  -  UFORadiant: Drag pane from edge of divider crashes
Posted Jun 07, 2011 - updated Jan 28, 2013
mattn (tlh2000) has been working on this issue since January 28, 2013 (20:47)
Issue details
  • Type of issue
    Bug report
  • Status
  • Assigned to
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Map Editor (UFORadiant)
  • Resolution
    Not determined
  • Priority
    3. Normal
  • Reproducability
    Not determined
  • Severity
    Not determined
  • Targetted for
    icon_milestones.png Not determined
  • Complexity
    icon_customdatatype.png Not determined
  • Platform
    icon_customdatatype.png Not determined
  • Architecture
    icon_customdatatype.png Not determined
Issue description
Item 2901 imported from sourceforge.net tracker on 2013-01-28 19:54:51

When dragging the edge of a pane to resize the views of UFORadiant, if you drag by the line on the edge, it will crash.

Steps 1. Open UFORadiant 2. Click and hold on a black line on a pane divider 3. Move the mouse

Version: built off master commit:ea029cde0c15a273f263e4edc8b907073d866a46 (* * Renamed xerox_ -> copier_) Since this may or may not be needed... Windows 7 SP1, Radeon HD5760, ATI 11.4, built with Muton's tool (pure MinGW, no codeblocks)

I've had this happen several times by accident, its gotten annoying enough to warrant submitting it. Dragging from the center part of the divider, or dragging when not on the divider at all do not crash. Only when dragging from the border.

Even though I can cause this to happen on command every time, in case it doesn't happen on other systems, including a video of it happening. In case anyone wonders, yellow highlight on mouse is no button, red is left.

Comments Ported from Sourceforge  ⇑ top
felyza (2011-06-07 04:30:29)  ⇑ top
How I do the crash purpose or accident
tlh2000 (2011-06-07 04:40:57)  ⇑ top
this is not reproducible here - can you please try to provide a stacktrace by running it via gdb?
felyza (2011-06-07 18:39:41)  ⇑ top
Rebuilt with full debug, and threw in insight.

Its stopping at Modifiers.cpp, line 100

105 // Returns a bit field with the according modifier flags set 106 unsigned int Modifiers::getKeyboardFlags (const unsigned int& state) 107 { 108 unsigned int returnValue = 0; 109 110 if ((state & GDK_CONTROL_MASK) != 0) { 111 returnValue |= (1 << getModifierBitIndex("CONTROL")); 112 } 113 114 if ((state & GDK_SHIFT_MASK) != 0) {

Stack according to insight

main gtk_main g_main_loop_run g_main_context_iterate g_main_context_dispatch XYWnd::xywnd_chasemouse(void*) XYWnd::mouseMoved(int, int, unsigned int const&) MouseEventManager::stateMatchesXYViewEvent(ui::XYViewEvent const&, unsigned int const&) Modifiers::getKeyboardFlags(unsigned int const&)

of course, local variables is buggy in gdb... trying to look at them crashes gdb
felyza (2011-06-07 18:42:49)  ⇑ top
oh, and its sigsegv
tlh2000 (2011-06-07 20:57:09)  ⇑ top
it would be cool if you could post the output of "bt full" from the gdb console. as the line numbers of the call stack are interesting, too.

if it stops at line 110 - please also try to get the value of modifierName

what do you mean with "of course local vars... crashes gdb"?

can&#039;t you do "p modifierName" at the gdb console?
Steps to reproduce this issue
Nothing entered.