[Gtkradiant] [Bug 53] mouseclick + drag in 2d view causes
stack overflow
Timothee Besset
gtkradiant@zerowing.idsoftware.com
Wed, 16 May 2001 14:43:02 +0200
Do you mean that the memory leaking in brush drags would be related to
status bar updates??
Which is fairly possible though, since I didn't try much running with BC
enabled on the Gtk dlls..
TTimo
At 10:25 16/05/2001 +0100, you wrote:
>if u comment out the updating of the statusbar labels
>the problem is removed => i was assuming it was
>related to the gtk_label_set_text function.
>
>--- bugzilla-daemon@zerowing.idsoftware.com wrote: >
>http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=53
> >
> >
> >
> >
> >
> > ------- Additional Comments From
> > ttimo@idsoftware.com 2001-05-13 15:29 -------
> > <RR2DO2> it's constantly increasing memory when
> > you're dragging a brush
> > <RR2DO2> and it keeps increasing as long as you
> > don't finalize it
> > <RR2DO2> so a brush created with one drag uses less
> > memory than one
> > created with two
> > [TTimo] BC detects leaks?
> > <RR2DO2> BC?
> > [TTimo] ah
> > [TTimo] food is there
> > [TTimo] bbl8r
> > <RR2DO2> k
> > [TTimo] BC = Bound Checkers
> > [TTimo] I will look when I get back
> > *** TTimo is now known as TTimoAFK
> > <SmallPileofGibs> RR2DO2: any click+drag does it
> > <SmallPileofGibs> in xy view
> > <RR2DO2> yup
> > <RR2DO2> it's odd
> > <SmallPileofGibs> any call to XYMousemove i guess
> > <SmallPileofGibs> xywnd:: mousemoved perhaps
> > <RR2DO2> hm
> > <RR2DO2> spog
> > <RR2DO2> // lbutton without selection = drag new
> > brush
> > <RR2DO2> if (m_nButtonstate == MK_LBUTTON &&
> > !m_bPress_selection &&
> > g_qeglobals.d_select_mode != sel_curvepoint)
> > <RR2DO2> {
> > <RR2DO2> NewBrushDrag (x, y);
> > <RR2DO2> return;
> > <RR2DO2> }
> > <RR2DO2> ^^ what if it already _is_ creating a new
> > brush?
> > <RR2DO2> the brush you are creating
> > <RR2DO2> is that a selected brush?
> > <SmallPileofGibs> no, that's MouseDown
> > <SmallPileofGibs> only happens on the click
> > <RR2DO2> no this is out of XY_MouseMoved
> > <SmallPileofGibs> hrm
> > <RR2DO2> what it seems to be doing is every frame
> > you move the mouse is
> > delete the selected brushes and recreate a new one
> > of the bigger size
> > <SmallPileofGibs> i did see that.. i remember going
> > through it and
> > figuring out what it did
> > <SmallPileofGibs> i think i ended up deciding it
> > wasn't caused by that
> > <SmallPileofGibs> probably
> > <RR2DO2> hm
> > <RR2DO2> having a brush just selected
> > <RR2DO2> and clicking outside of it, not dragging,
> > seems to do the same
> > <RR2DO2> (increasing memory with no reason that is)
> > <SmallPileofGibs> yes
> > <RR2DO2> hm
> > <SmallPileofGibs> holding ctrl+LMB and dragging does
> > the same
> > <SmallPileofGibs> =)
> > <RR2DO2> maybe it's the undo system?
> > <SmallPileofGibs> with nothing selected
> > <SmallPileofGibs> after creating no brushes
> > <SmallPileofGibs> hrm
> > <SmallPileofGibs> djbob tracked it to gtk-1.3.dll
> > <SmallPileofGibs> so did i
> > <RR2DO2> hm :/
> > <SmallPileofGibs> djbob got further
> > <SmallPileofGibs> but we could be both wrong
> > *** Equim (equim@host213-122-145-16.btinternet.com)
> > has joined #gtkradiant
> > *** neo279 (Lister279@du-002-0035.freeuk.com) has
> > left IRC []
> > [TTimoAFK] how do you watch memory usage
> > *** TTimoAFK is now known as TTimo
> > <RR2DO2> win2k
> > [TTimo] I'm gonna try against a BC build see if it
> > reports anything
> > <RR2DO2> it shows how much KB an app is using
> > [TTimo] ok
> > [TTimo] just checking
> > [TTimo] (that's not very fine-grained)
> > <RR2DO2> it does clear all the memory on exit though
> > <RR2DO2> so it gets allocated and destroyed nicely
> > it seems
> > <RR2DO2> but I suspect it gets allocated at wrong
> > and too many times
> > [TTimo] you mean it's not leaking then
> > <SmallPileofGibs> eventually it overflows the stack
> > with calls to
> > something.. could be in gtk-1.3.dll
> > <SmallPileofGibs> it's not leaking no, just seems to
> > be an allocating in
> > an ever-increasing loop or something
> > [TTimo] and when does that get released?
> > [TTimo] when you release the mouse button?
> > <RR2DO2> no
> > <RR2DO2> when you close radiant
> > [TTimo] so it's not leaking
> > [TTimo] it's released normally
> > [TTimo] I don't understand how you can assert that
> > it's not a leak if you say
> > the mem is released when you exit Radiant
> > *** W2k (~w2k@as1-5-1.ulr.s.bonet.se) has left IRC
> > [Read error to W2k[as1-5-
> > 1.ulr.s.bonet.se]: Connection reset by peer]
> > *** W2k (~w2k@as1-5-1.ulr.s.bonet.se) has joined
> > #gtkradiant
> > *** W2k is now known as W2k[cs]
> > <SmallPileofGibs> TTimo: the leak (or no) is not the
> > problem
> > <SmallPileofGibs> the problem is the stack overflow
> > and crash that
> > happens too =)
> > *** W2k[cs] is now known as W2k
> > *** Equim is now known as Equim-q3
> > [TTimo] those two things are probably related and
> > the actual problem is to find
> > out what happens .. if BC would output a link error
> > it would be the most
> > straightforward way to find out
> > [TTimo] leak error
> > [TTimo] god the winding code is a f*g hack
> > [TTimo] it's utterly ugly
> > <SmallPileofGibs> hrm, i don't think i tracked it to
> > gtk-1.3
> > <SmallPileofGibs> it's in XY_draw
> > <SmallPileofGibs> pasting stack..
> > <SmallPileofGibs> $$$00001() line 79
> > <SmallPileofGibs> XYWnd::XY_Draw() line 2875
> > <SmallPileofGibs> XYWnd::OnExpose() line 3228
> > <SmallPileofGibs> expose(_GtkWidget * 0x0149e090,
> > _GdkEventExpose *
> > 0x0003720c, void * 0x03988268) line 63
> > <SmallPileofGibs> GTK-1.3! 006e3eba()
> > <SmallPileofGibs> 00010fcc()
> > <SmallPileofGibs> 014a2ca0()
> > <SmallPileofGibs> $$$00001() line 79 <--
> > chkstk.asm.. stack overflow
> > detecting thingy?
> > <SmallPileofGibs> XYWnd::XY_Draw() line 2875 <--
> > just after DrawPathLines
> > ()
> > <SmallPileofGibs> ok, i crashed it in BC
> > <SmallPileofGibs> what should i be looking for?
> > *** Equim-q3 is now known as Equim
> > [TTimo] I cleaned up some dirty stuff
> > [TTimo] well that's easy
> > [TTimo] break in XY_Draw
> > [TTimo] watch the stack
> > [TTimo] put a static
> > [TTimo] and break after a given number of calls
> > [TTimo] it's probably in a situation where it's
> > infinite looping
> > <SmallPileofGibs> the stack would normally show a
> > long list of calls
> > tho..?
> > <SmallPileofGibs> hrm
> > <SmallPileofGibs> i spose it doesn't ncessarily
> > recurse
> > [TTimo] long, but never growing infinitely
> > [TTimo] if it stack overflows
> > [TTimo] then it's probably recursing
> > *** neo279 (Lister279@du-006-0055.freeuk.com) has
> > joined #gtkradiant
> > <SmallPileofGibs> well, when i caused infinite
> > recursion and got stack
> > overflows, i had a really big stack =)
> > <SmallPileofGibs> but this shows a small stack
> > [TTimo] the trick is to catch it inside the
> > recursion
> > <SmallPileofGibs> how can you have a stack overflow
> > with only 8 calls in
> > the stack?
> > [TTimo] if you just put a break it will beak on the
> > first
> > [TTimo] break even
> > [TTimo] you can't catch recursion errors with debug
> > breaks
> > <SmallPileofGibs> but... this function is called
> > thousands of times with
> > no problem
> > [TTimo] use a static
> > <SmallPileofGibs> and it just decided to crash after
> > a certain number of
> > calls
> > <SmallPileofGibs> a static?
> > <leaf> a static is being a prick as usual
> > <SmallPileofGibs> ok leaf
> > [TTimo] I'll look now
> > <SmallPileofGibs> actually, mouse dragging just
> > causes a large number of
> >
>=== message truncated ===
>
>
>=====
>First there was nothing, then it exploded.
>To err is human, to really f**k things up requires windoze.
>
>____________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
>or your free @yahoo.ie address at http://mail.yahoo.ie
>
>_______________________________________________
>Gtkradiant mailing list
>Gtkradiant@zerowing.idsoftware.com
>http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant