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

  1. #1
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886

    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)

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    37,972
    For some corruption issues, you could try using a 'data breakpoint' in GDB.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    Quote Originally Posted by Salem View Post
    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

  4. #4
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    Quote Originally Posted by awsdert View Post
    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

  5. #5
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    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

  6. #6
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    Quote Originally Posted by awsdert View Post
    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.

  7. #7
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    Quote Originally Posted by awsdert View Post
    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.
    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
    Last edited by awsdert; 04-02-2020 at 05:33 AM.

  8. #8
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    Quote Originally Posted by awsdert View Post
    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

  9. #9
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    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
    Last edited by awsdert; 04-02-2020 at 10:32 AM.

  10. #10
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    Quote Originally Posted by awsdert View Post
    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)

  11. #11
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    886
    Quote Originally Posted by awsdert View Post
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Memory allocation/corruption
    By TheEngineer in forum C Programming
    Replies: 9
    Last Post: 09-09-2009, 08:07 AM
  2. Memory Corruption
    By mataharistudios in forum C++ Programming
    Replies: 4
    Last Post: 02-20-2009, 04:29 AM
  3. Strange memory corruption
    By kwyjibo in forum C Programming
    Replies: 5
    Last Post: 10-29-2008, 03:59 AM
  4. Memory Corruption
    By cyreon in forum C Programming
    Replies: 3
    Last Post: 11-15-2007, 03:52 AM
  5. Debugging Memory Corruption
    By Maskawanian in forum C Programming
    Replies: 4
    Last Post: 05-24-2007, 04:47 PM

Tags for this Thread