[Gtkradiant] [Bug 53] mouseclick + drag in 2d view causes stack overflow
djbob
gtkradiant@zerowing.idsoftware.com
Wed, 16 May 2001 10:25:00 +0100 (BST)
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