[Gtkradiant] [Bug 53] mouseclick + drag in 2d view causes stack overflow
Goetzenzar
gtkradiant@zerowing.idsoftware.com
Mon, 14 May 2001 08:11:05 +0200
additional info:
start gtkradiantrc2
create a brush
increase/decrease the size of it (y axis)
(hold mouse button, move "up and down")
after 1 1/2 minute i get this:
(the german words can be translated to : "GTKRADIANT-1 caused an Stackfault
in Modul KERNEL32.DLL with 016f:bff64277."
-stack overflow i guess
GTKRADIANT-1 verursachte einen Stapelfehler in Modul KERNEL32.DLL bei
016f:bff64277.
Register:
EAX=81969e1c CS=016f EIP=bff64277 EFLGS=00000287
EBX=08b70518 SS=0177 ESP=008f9fdc EBP=00008fd4
ECX=c1660180 DS=0177 ESI=00000001 FS=3287
EDX=00020b24 ES=0177 EDI=008fffff GS=0000
Bytes bei CS:EIP:
eb 95 8b 54 24 04 50 e8 04 00 00 00 58 c2 04 00
Stapelwerte:
bff61547 006534c0 00b10670 00000000 00b10370 00653507 00000001 008fa010
00000000 00000000 00000000 00000000 00b10670 00000000 0000d90b 00000000
after that i tested with ctrl+ brushdrag, i agree with spog,
u get the error faster then:
(some numbers changed)
GTKRADIANT-1 verursachte einen Stapelfehler in Modul KERNEL32.DLL bei
016f:bff64277.
Register:
EAX=8195a290 CS=016f EIP=bff64277 EFLGS=00000287
EBX=08b70518 SS=0177 ESP=008f9fdc EBP=00008fd4
ECX=c164e960 DS=0177 ESI=00000001 FS=2a5f
EDX=00020b24 ES=0177 EDI=008fffff GS=0000
Bytes bei CS:EIP:
eb 95 8b 54 24 04 50 e8 04 00 00 00 58 c2 04 00
Stapelwerte:
bff61547 006534c0 00b10670 00000000 00b10370 00653507 00000001 008fa010
00000000 00000000 00000000 00000000 00b10670 00000000 0000d90b 00000000
and when i pause between the drags or when i edit normal
(also when doing entity editing most of the time and only a bit brushwork) i
receive the 2d pan view slowdown:
u dont have control over it (the pan 2d view function) anymore.
Hope that helped.
----- Original Message -----
From: "Goetzenzar" <Goetzenzar@gmx.net>
To: <gtkradiant@zerowing.idsoftware.com>
Sent: Monday, May 14, 2001 7:38 AM
Subject: Re: [Gtkradiant] [Bug 53] mouseclick + drag in 2d view causes stack
overflow
> this bug should have highest priority!
> its no little bug damn, i simply cant edit more than 5-10minutes in
> gtkradiant!
>
> i get no error message (most of the time) but a serious slowdown (pan 2d
> view function)
> (tested also with rc2)
>
> i'm using windows millenium
>
> Goetzenzar
>
>
>
> ----- Original Message -----
> From: <bugzilla-daemon@zerowing.idsoftware.com>
> To: <gtkradiant@zerowing.idsoftware.com>
> Sent: Sunday, May 13, 2001 10:29 PM
> Subject: [Gtkradiant] [Bug 53] mouseclick + drag in 2d view causes stack
> overflow
>
>
> > 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
> > calls to expose()
> > <SmallPileofGibs> which updates the windows
> > <SmallPileofGibs> so perhaps the number of window updates is the problem
> > [TTimo] crashed MSDev
> > <SmallPileofGibs> ouch
> > [TTimo] ok that was a bad crash
> > [TTimo] it fucked a bunch of things
> > *** ^Fishman (blah@206.49.96.50) has joined #gtkradiant
> > *** Mode change [+o ^Fishman] on #gtkradiant by ChanServ
> > <SmallPileofGibs> =/
> > [TTimo] hey ^Fishman
> > <leaf> ^Fishman is probably with Doom 3, but that's just a desktop
beside
> the
> > pic of doom its just loading a map
> > <^Fishman> hey TTimo
> > <^Fishman> leaf, forget ^Fishman
> > <leaf> ^Fishman: I forgot ^fishman
> > [TTimo] I still can't reproduce anything with that bug
> > [TTimo] you use one brush or more?
> > *** Equim (equim@host213-122-145-16.btinternet.com) has left IRC [Excess
> Idle]
> > *** neo279 is now known as MP5
> > *** MP5 is now known as neo279
> > [TTimo] I'm not getting any sign of recursion .. I can't reproduce the
bug
> > either so I guess that's expected
> > *** neo279 (Lister279@du-006-0055.freeuk.com) has left IRC []
> > [TTimo] http://www.gtkradiant.com/test/q3radiant_rectst.zip
> > [TTimo] spog can you grab this build and try to reproduce the crash on
it?
> > [TTimo] tell me if it starts printing error messages about recursion
> > <SmallPileofGibs> ok
> > <SmallPileofGibs> TTimo: sometimes it never happens
> > <SmallPileofGibs> others it happens with no brushes
> > <SmallPileofGibs> it's wierd.. i can usually reproduce it really easily
> > <SmallPileofGibs> but last night i couldn't
> > [TTimo] I was never able to reproduce it
> > <SmallPileofGibs> yep, just reproduced it
> > <SmallPileofGibs> what did you do when you were trying to reproduce it?
> > [TTimo] does it send out recursion messages?
> > <SmallPileofGibs> none
> > [TTimo] <SmallPileofGibs> $$$00001() line 79
> > [TTimo] <SmallPileofGibs> XYWnd::XY_Draw() line 2875
> > [TTimo] <SmallPileofGibs> XYWnd::OnExpose() line 3228
> > [TTimo] <SmallPileofGibs> expose(_GtkWidget * 0x0149e090,
_GdkEventExpose
> > * 0x0003720c, void * 0x03988268) line 63
> > [TTimo] <SmallPileofGibs> GTK-1.3! 006e3eba()
> > [TTimo] <SmallPileofGibs> 00010fcc()
> > [TTimo] <SmallPileofGibs> 014a2ca0()
> > [TTimo] <SmallPileofGibs> $$$00001() line 79 <-- chkstk.asm.. stack
> > overflow detecting thingy?
> > [TTimo] <SmallPileofGibs> XYWnd::XY_Draw() line 2875 <-- just after
> > DrawPathLines()
> > [TTimo] if that really happens then it WILL output a recursion error msg
> > <SmallPileofGibs> it says.. "The exception unknown software exception
> > (0xc00000fd) occurred in the application at location 0x00512c37
> > <SmallPileofGibs> "
> > <SmallPileofGibs> hmm.. it doesn't look to me as if it's being caused by
> > recursion
> > [TTimo] the stack trace you pasted shows a recursion though
> > <SmallPileofGibs> oh.. sorry
> > <SmallPileofGibs> how can you tell? =)
> > [TTimo] and if that was happening the build I sent would tell you
> > [TTimo] and you said you can't reproduce with the RC2 binary?
> > <SmallPileofGibs> it gives a message in msdev?
> > [TTimo] no in GtkRad console
> > <SmallPileofGibs> i looked in the console.. it said nothing
> > <SmallPileofGibs> i'll download the RC2 installer now
> > [TTimo] you said you had an earlier build on which you could not
reproduce
> > <SmallPileofGibs> i couldn't reproduce with RC1 the other night
> > [TTimo] ah
> > <SmallPileofGibs> but then i tried today and i could
> > <SmallPileofGibs> and also on a build of RC2 from cvs today
> > <SmallPileofGibs> i could
> > [TTimo] yeah
> > [TTimo] you can reproduce when it's running against Gtk libs you built
> yourself
> > <SmallPileofGibs> hmm.. lemme check
> > <SmallPileofGibs> i'll confirm with RC2
> > [TTimo] both the linking and the running matter
> > [TTimo] ok I'll let go on this bug and look at something else for now
> >
> > _______________________________________________
> > Gtkradiant mailing list
> > Gtkradiant@zerowing.idsoftware.com
> > http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant
> >
>
>
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant@zerowing.idsoftware.com
> http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant
>