Thread: Need help finding the cause of a probably memory corruption

Tried using gede but at the point of gasp crashing it is somehow expects different to what it receives (think it said expecting var but got }), I managed to find the line of code it crashes at by slapping a bunch of "fprintf( stderr ..." statements in and the line is 1121 of proc.c in this version of the code:

GitHub - awsdert/gasp at 6832e65403a867da1773b668f69e16854ac203f6

Any help identifying the source of corruption would be appreciated, even if it's suggestions for how to find it (so far I did a session search with variants of "memset( dump, 0" and "dump->*.data =", nothing I found lead me to the corruption although I think I fixed a few possible factors)

Originally Posted by Salem

For some corruption issues, you could try using a 'data breakpoint' in GDB.

The problem is it's not a global variable and it floats around a fair bit making it hard to track without just printing it's data, also I suck at using command line debugging which is why I'm using gede, a gui that wraps around gdb

Originally Posted by awsdert

The problem is it's not a global variable and it floats around a fair bit making it hard to track without just printing it's data, also I suck at using command line debugging which is why I'm using gede, a gui that wraps around gdb

Just reattempted a debugging session only to find gede pops up that error upon launching deep-gasp-d.elf, I'm starting to think gede doesn't like being launched under pkexec from user mode, if you have any idea how to resolve that I might be able to try tracking the value with a watch on "dump->used.data" and "dump->data.data", not sure if that'll work out but better than nothing

Managedto find the source of that corrupt ion after noticing a specific instance of clearing a sub object to 0 doesn't preserve the given buffer and size values, after moving the common clear out code from the open/shut functions into a single init function that does the preservation via 2 given parameters and calling that instead it cleared up that corruption, now I'm stuck at another, I think I thought of something earlier in the day that would probably have fixed it but I was busy at the time and now I forgotten, I would appreciate any attempt to look through my code for the problem:

GitHub - awsdert/gasp at 59949f3c71d310ac9dccbd21bb479b5bddd47122

The only thing I can remember of the thought was that it was somewhere in lua_process.c

Originally Posted by awsdert

Managedto find the source of that corrupt ion after noticing a specific instance of clearing a sub object to 0 doesn't preserve the given buffer and size values, after moving the common clear out code from the open/shut functions into a single init function that does the preservation via 2 given parameters and calling that instead it cleared up that corruption, now I'm stuck at another, I think I thought of something earlier in the day that would probably have fixed it but I was busy at the time and now I forgotten, I would appreciate any attempt to look through my code for the problem:

GitHub - awsdert/gasp at 59949f3c71d310ac9dccbd21bb479b5bddd47122

The only thing I can remember of the thought was that it was somewhere in lua_process.c

Remembered the thought, it was about how I was leaking memory when clearing the data in a dump_t object, unfortunately attempting to resolve that problem lead to gasp crashing before it even reported anything via the 'REPORT' macros, however I'm tired now so I plan to continue trying 2mw, also my internet connection is on the fritz so I'll probably just go to sleep in a little bit.

Originally Posted by awsdert

It seem my fixes were unrelated to the crash, apparently I got lucky for a while where this crash should've occurred, I forced it to appear in every place it should do so by adding a concatenation before the call that should crash on nil (lua this time), however now I am getting a crash in a bizzare spot after fixing all the ones that came went unnoticed before now, the bizzare spot is here:

Code:

	local function range2str(from,upto,desc)
		return ((string.format( "%X - %X %s", from, upto, desc ))
			or "(nil)")
	end
...
		list = {
			txt = {},
			raw = {
				from = 0, upto = gasp.ptrlimit(), desc = "Default"
			}
		}
		
		if GUI.cheat and GUI.cheat.app then
			tmp = GUI.cheat.app.regions or {}
			for i = 1,#tmp,1 do
				v = tmp[i]
				list.raw[i+1] = v
			end
		end
		
		tmp = list.raw
		for i = 1,#tmp,1 do
			v = tmp[i]
			list.txt[i] = range2str( v.from, v.upto, v.desc )
		end
		
		if not scan.region or scan.region < 1 then
			scan.region = 1
		end
		
		tmp = list.txt
		v = tmp[1]
		scan.region = nk.combo(
			ctx, tmp, scan.region,
			pad_height( font, v ),
			{
				pad_width( font, v ) * 2,
				pad_height( font, v ) * 2
			}
		)

Any ideas what might be causing it?

The tree:
GitHub - awsdert/gasp at e1e361af79385e495d7a9ac10f6926d5ca8c6826

The file the above code is in:
gasp/scan.lua at e1e361af79385e495d7a9ac10f6926d5ca8c6826 * awsdert/gasp * GitHub

Edit: The traceback from lua is:

Code:

lua/gui_mode.lua:108: in function 'pad_height'
lua/scan.lua:69: in field 'func'

At the first pad_height call which for reference is defined as such:

Code:

function pad_width(font,text)
	if font == nil or text == nil then
		print(debug.traceback())
	end
	text = "" .. text
	return math.ceil((font:width(font:height(),text)) * 1.2)
end

function pad_height(font,text)
	if font == nil or text == nil then
		print(debug.traceback())
	end
	text = "" .. text
	return math.ceil((font:height(text)) * 1.2)
end

Never mind found the issue with that one, turned out I forgot to put the members of the 1st item in an object so it somehow never filled the text list, still getting a sudden crash when I try to scan though so attempting to find where it crashes

Originally Posted by awsdert

Found where it crashes:

Code:

int dump_files_init( dump_t *dump ) {
	uint i;
	uchar *_;
	nodes_t *nodes;
	space_t *space;
	
	if ( !dump )
		return EDESTADDRREQ;
	
	REPORT("Setting C code pointers")
	nodes = dump->nodes;
	space = &(nodes->space);
		
	REPORT("Clearing entire object")
	(void)memset( dump, 0, sizeof( dump_t ) );
	
	REPORT("Forcing invalid files descriptors")
	dump->info.fd = dump->used.fd = dump->data.fd = -1;
	
	REPORT("Restoring pointer to nodes_t object holding mapping info");
	dump->nodes = nodes;
	
	REPORT("Calculating local buffer pointers")
	_ = dump->_;
	for ( i = 0; i < DUMP_LOC_NODE_UPTO; ++i ) {
		dump->__[i] = _ + (i * DUMP_LOC_NODE_SIZE);
	}
	
	REPORT("Setting named pointers to calculated pointers")
	REPORT("Setting named pointer for info") // This is printed
	dump->info.data = space->block;
	REPORT("Setting named pointer for used address") // This is not
	dump->used.data = dump->__[DUMP_LOC_NODE_USED];
	REPORT("Setting named pointer for data")
	dump->data.data = dump->__[DUMP_LOC_NODE_DATA];
	
	REPORT("Setting named sizes to correct sizes")
	dump->info.size = space->given;
	dump->used.size = DUMP_LOC_NODE_SIZE;
	dump->data.size = DUMP_LOC_NODE_SIZE;
	
	return 0;
}

Seems it chokes on trying to use the space_t object which is declared like this:

Code:

typedef struct space {
	size_t given;
	void *block;
} space_t;

...
	
typedef size_t node_t;
typedef struct nodes {
	node_t focus;
	node_t count;
	node_t total;
	space_t space;
} nodes_t, scan_t;

I'm not seeing why it's crashing, anyone have any ideas?

Edit: Just in case, the current tree:
GitHub - awsdert/gasp at af279617499b9418d6d578e90471858f68059d6a

Found the cause of that one, turns out I need to set the value of nodes earlier than I had placed it, didn't expect it to be NULL because it didn't crash when setting the 'space' pointer, finally got back into the dump thread only to find it crashing when attempting to retrieve the list of mappings, I'll look at that after having something to eat and possibly a bath, need a break from my screen after all (even if it is projected from behind me there is still eventual eye strain, jsut takes longer than a LCD or LED etc)

Originally Posted by awsdert

Found the cause of that one, turns out I need to set the value of nodes earlier than I had placed it, didn't expect it to be NULL because it didn't crash when setting the 'space' pointer, finally got back into the dump thread only to find it crashing when attempting to retrieve the list of mappings, I'll look at that after having something to eat and possibly a bath, need a break from my screen after all (even if it is projected from behind me there is still eventual eye strain, jsut takes longer than a LCD or LED etc)

Turned out the crash was caused by a mishandled conversion of code, fixed and working without crashes now, now I just gotta figure out why the scan end prematurely.