[Uml-user] Crash of UML 1.1 beta 1 on Creating a Use Case View

[Sebastian Stein]

Jonathan Riddell <jr at jriddell.org> [021014 20:33]:
> This sounds a lot like the last bug I posted to the uml-user list.

Yes, this seems to be the case. I think I will add a bug to the tracker
tomorrow.

> Unfortunatly I can't reproduce it either.  Getting a backtrace is great
> but I can't see where it would crash, probably on the first line of
> worktoolbar::buttonchanged at a hunch.

I disagree. I think the crash must happen later. Please look again at the
backtrace:

   #7  0x000318f0 in WorkToolBar::buttonChanged(int) ()
   #8  0x000a45a4 in WorkToolBar::qt_invoke(int, QUObject*) ()
   #9  0xfde4fea0 in QObject::activate_signal(QConnectionList*, QUObject*)
()
      from /usr/local/qt3/lib/libqt-mt.so.3
   #10 0xfde4ff4c in QObject::activate_signal(int, int) ()
      from /usr/local/qt3/lib/libqt-mt.so.3
   #11 0xfe991810 in KToolBar::qt_emit(int, QUObject*) ()
      from /usr/local/kde3/lib/libkdeui.so.4
   #12 0x000a45e0 in WorkToolBar::qt_emit(int, QUObject*) ()

So #12 is a call to qt_emit from WorkToolBar. So if I understand it
correctly, the crash must happen after an emit in this function.
Unfortunally there are 2 emits but one of them is in an if statement.

Or must I read the BT the other way around? Maybe the problem is, that the
function itself emits a signal?

Could you explain what is happening in the function. I mean what are the
checks for the arrow state for?

Steinchen
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial