[Gtkradiant] [Bug 53] mouseclick + drag in 2d view causes stack overflow

Sun, 13 May 2001 15:29:29 -0500

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