Long Strings Freeze MaxIDE using DebugStop

Archives Forums/BlitzMax Bug Reports/Long Strings Freeze MaxIDE using DebugStop

BlitzProg

(Posted 2010) [#1]

'Creating string containing 'size' times a random character
Local size=2^20 '1Mbytes
Local bank:TBank=CreateBank(size)
For i=0 To size-1 ; PokeByte(bank,i,"0"[0]) ; Next 
Local str$=String.frombytes(BankBuf(bank),size)


'try to go in debug - use Debug Build
Print "entering debug mode"
DebugStop
Print "exiting debug mode"

---

the higher the size, the longuer Debugstop will have to work.

if you force the termination by either clicking the big red button or killing the process, BlitzMax will either freeze(but if may not and display the string into the BlitzMax output stream if you are using a low enough size value). It seems to freeze past a size of 2^19. If it freeze it won't unfreeze, you'll have to kill your MaxIde Process. :(

This effectively prevent me from debuging one of my recent software that deal with a 100K line long text file (size = 3.4Megabytes) - don't ask why, i needed it, and everything, from the researches to Areatextfield formating works fine and very fast. ;)

Window XP - Bmax139

I hope i'm posting this in the correct place.

SebHoll

(Posted 2010) [#2]

Your demo on my PC doesn't crash MaxIDE but you're right, it definitely makes it stall for a long period of time. If you leave it long enough it seems to come round. I may do some investigation if I get some free time.

Edit: BLIde takes a while too, but no where near as long as MaxIDE.

ziggy

(Posted 2010) [#3]

I'm pretty sure this is related to the fact that the aplication being debugged is sending all the string contents across the error pipe, and the buffersize of this pipe is small (I think it is 4Kbytes by default). The fact that the pipe is small, adds several syncronization requests between applications and it can take a while. The data being sent in this example is a lot larger than the standard pipe buffer size, and this can slow down things. Eitherway, I don't see any bug here.

EDIT: BLIde is faster here becouse it's performing the read operations in a not syncronic way, and flushing the stream freqüently, in a separated thread, so it can be done without affecting responsiveness of the IDE. This approach works very well (I would suggest to give it a try on MaxIDE). If anyone is interested, here's a brief explanation of how it's working on BLIde since june 2009, and it works rock solid.

SebHoll

(Posted 2010) [#4]

You're right... The only real solution is to increase the buffer size for the pipes between processes.

Fix to pub.mod/freeproceess.mod/freeprocess.c's fdProcess():

#define PIPE_SIZE (1<<18)

int fdProcess( BBString *cmd,int *procin,int *procout,int *procerr,int flags)
{
	int res;
	int pflags=CREATE_NEW_PROCESS_GROUP;
	PROCESS_INFORMATION *pi;
	SECURITY_ATTRIBUTES sa={sizeof(sa),0,1};
	HANDLE istr,p_ostr;	//our in-stream, process out-stream
	HANDLE ostr,p_istr;	//our out-stream, process in-stream
	HANDLE estr,p_estr;			//our errin-stream, process errout-stream

	if( !CreatePipe( &istr,&p_ostr,&sa, PIPE_SIZE ) ){
		//unable to create pipe
		return 0;
	}

	if( !CreatePipe( &p_istr,&ostr,&sa, PIPE_SIZE ) ){
		CloseHandle( istr );
		CloseHandle( p_ostr );
		//ditto
		return 0;
	}

	if (!CreatePipe(&estr,&p_estr,&sa,PIPE_SIZE )) {
		CloseHandle( istr );
		CloseHandle( p_ostr );
		CloseHandle( ostr );
		CloseHandle( p_istr );
		//unable to create pipe
		return 0;
	}

	pi=(PROCESS_INFORMATION*)calloc(1,sizeof(PROCESS_INFORMATION));
	
	if( _bbusew ){
		STARTUPINFOW si={sizeof(si)};

		si.dwFlags=STARTF_USESTDHANDLES;
		si.wShowWindow=SW_HIDE;
		si.hStdInput=p_istr;
		si.hStdOutput=p_ostr;
		si.hStdError=p_estr;
		if (flags&HIDECONSOLE) {
			si.dwFlags|=STARTF_USESHOWWINDOW;
			si.wShowWindow=SW_HIDE;
		}
		else {
			pflags|=DETACHED_PROCESS;
		}
		res=CreateProcessW( 0,bbTmpWString(cmd),0,0,-1,pflags,0,0,&si,pi );
	}else{
		STARTUPINFO si={sizeof(si)};

		si.dwFlags=STARTF_USESTDHANDLES;
		si.wShowWindow=SW_HIDE;
		si.hStdInput=p_istr;
		si.hStdOutput=p_ostr;
		si.hStdError=p_estr;
		if (flags&HIDECONSOLE) {
			si.dwFlags|=STARTF_USESHOWWINDOW;
			si.wShowWindow=SW_HIDE;
		}
		else {
			pflags|=DETACHED_PROCESS;
		}
		res=CreateProcess( 0,bbTmpCString(cmd),0,0,-1,pflags,0,0,&si,pi );
	}
	
	if( !res ){
		CloseHandle( istr );
		CloseHandle( ostr );
		CloseHandle( estr );
		CloseHandle( p_istr );
		CloseHandle( p_ostr );
		CloseHandle( p_estr );
		return 0;
	}
	
	CloseHandle( pi->hThread );
	
	*procin=(int)istr;
	*procout=(int)ostr;
	*procerr=(int)estr;

	CloseHandle( p_istr );
	CloseHandle( p_ostr );
	CloseHandle( p_estr );
	
	return (int)pi;
}

This increases the buffer size to 256KB which makes MaxIDE a LOT snappier (setting PIPE_SIZE to (1<<19) makes it almost instantaneous).

Bingo! :-)

BlitzProg

(Posted 2010) [#5]

SebHoll > I do not crash if i let it process all the way to the end. However if i don't and attempt to stop (using the appropriate debug button or by killing the process) it is possible for Bmax to freeze, probably trying to debug a process that no longuer exists (At this point my MaxIDE is done for, i cannot save/unfreeze/quit) :(

Thanks for the fix by the way. I should have guessed it would be a problem of this kind, because i've also used Banks in the past and opted for size increase to gain speed. ^_^

Edit - Oh and also I hope i'm not speaking in a way that looks too wierd, i'm not english in the first place and i've learnt nearly all of it through Internet :)

SebHoll

(Posted 2010) [#6]

*bump*

Looks like this missed BlitzMax 1.40 release which is a shame.

marksibly

(Posted 2010) [#7]

Hi,

> The only real solution is to increase the buffer size for the pipes between processes.

...or perhaps the size of strings sent to the debugger could be clamped to 1024 or something?

> This increases the buffer size to 256KB

Is everyone OK with that? I mean, it's 'just' 256K and all, but...

plash

(Posted 2010) [#8]

Maybe the buffer size should be changeable from the Max side?

marksibly

(Posted 2010) [#9]

Hi,

But can the IDE even *display* 1MB strings?

Is there really any point in throwing all this mem out the window in the first place?!?

And what about non-win32 fixes?

marksibly

(Posted 2010) [#10]

Hi,

I'm much more comfortable with adding something like this to the start of DebugEscapeString in debugger_mt.stdio.bmx:

If s.length>4096 s=s[..4096] '

Yes, it means you can't debug *huge* strings - but can you really work with such strings from within the debugger anyway? Aren't they too big for the debugger window, or am I missing something here?