SQLite Forum

below function will free the heap memory for running application or not

below function will free the heap memory for running application or not

(1) By Mangal Prajapati (V16be1p11) on 2022-01-27 07:42:31 [link] [source]

I have concern regarding free the heap memory while lots of records we get through the query.

my code is look like below when sqlite query i use

if(app::dbmanager::SqliteManager::GetDBInstance()->openDatabase() == SUCCESS)

	sql<<"select intTicketTypeID,substr(strTicketNo,7),dteTicketDateTime,TR.intFromStationID,TR.intToStationID" \
			<<",(select strStageCode  from TBLROUTESTATIONMASTER RSM where  RSM.intRouteID = TR.intRouteID and RSM.intStationID = TR.intFromStationID AND RSM.bActive=1 AND RSM.bDeleted=0 )  as FromStaionStageCode"\
			<<",(select strStageCode  from TBLROUTESTATIONMASTER RSM where  RSM.intRouteID = TR.intRouteID and RSM.intStationID = TR.intToStationID   AND RSM.bActive=1 AND RSM.bDeleted=0 )  as ToStaionStageCode"\
			<<",sum(intFullTickets) as AdultQty "\
			<<",sum(intHalfTickets)  as HalfQty "\
			<<",sum(intTotalTicketAmount/100)  as TotalTicketAmount "\
			<<" from tblTicketTransactions TR "\
			<<" where strWayBillNo ='"<<strWaybillNo<<"' "\
			<<" AND intTripID='"<<strInspectionReportTripID<<"' "\
			<<" group by strTicketNo "\
			<<" order by dteTicketDateTime asc;";

	strquery =  sql.str();
	DBGF_TRACE("\n InspectionReportStep::execute(): strquery = %s\n",strquery);
	result = sqlite3_exec(app::dbmanager::SqliteManager::GetDBInstance()->handle, strquery.c_str(), &callBackTicketDataList, 0, &errMsg);
	if(result == SQLITE_OK)


			//return boomer::transaction::trOk;
			//boomer::ui::vc::AlertVC::displayError("ERROR","Ticket Data Not found.");
			//return boomer::transaction::trCancel;
		//Insert Error Log
		app::Header::AFCSErrorLogs afcsErrorLogs(pTransactionData);
		return boomer::transaction::trCancel;

In my application i am using below function to free the heap memory.

will below function will free the heap memory ?

sqlite3_int64 intBeforeReleaseInBG = sqlite3_memory_used(); printf("intBeforeReleaseInBG = %lldn", intBeforeReleaseInBG);

int intReleaseMemory = sqlite3_release_memory(10000);
printf("intReleaseMemory = %dn", intReleaseMemory);

sqlite3_int64 intAfterReleaseInBG = sqlite3_memory_used();


sqlite3_int64 intSoftHeap = sqlite3_soft_heap_limit64(250000); printf("intSoftHeap = %lldn", intSoftHeap); printf("intAfterReleaseInBG = %lldn", intAfterReleaseInBG);

(2) By Gunter Hick (gunter_hick) on 2022-01-27 11:00:23 in reply to 1 [link] [source]

Maybe. The effect will most likely be to evict currently unused pages from the page cache, which will make SQLite have to read them again.

Perhaps you should consider using the MEMSYS5 zero-malloc memory allocator (which is designed for use in embedded systems) to limit SQLite to a defined maximum. See https://sqlite.org/malloc.html

(3) By Mangal Prajapati (V16be1p11) on 2022-01-27 11:19:17 in reply to 2 [link] [source]

Can you elaborate some more. Because I am not understanding what you have replied.

(4) By Gunter Hick (gunter_hick) on 2022-01-27 13:23:57 in reply to 3 [link] [source]

Use the MEMSYS5 allocator as described on the linked page to limit SQLite memory use to a predefined maximum.

(5) By Bradley Spatz (bspatz) on 2022-01-28 19:18:06 in reply to 2 [link] [source]


Interesting read. +1

I did note a typo however, in section 4.1: "elements 3 through 7" should probably be "3 through 6" instead. Is this a good place to report?

(6) By Larry Brasfield (larrybr) on 2022-01-28 19:31:10 in reply to 5 [link] [source]

Thanks. Fixed here.

(7) By Keith Medcalf (kmedcalf) on 2022-01-28 20:30:58 in reply to 1 [source]

What exactly are you trying to accomplish and why?

RAM that has been purchased but is unused was a waste of money.

(8) By Mangal Prajapati (V16be1p11) on 2022-01-31 06:34:48 in reply to 7 [link] [source]

free the heap memory for running application when sqlite query result is used in application.

Means query get executed, it's result we use in application then free the heap memory.

(9) By Gunter Hick (gunter_hick) on 2022-01-31 07:41:52 in reply to 8 [link] [source]

This is only going to make your application run slowly due to excessive IO.

The freed memory is NOT returned to the OS for OTHER processes to use. It is just put on the heap to be used by the SAME process for running the next query.

All you are achieving is converting pages in the page cache (which got there by doing IO, which was expensive, and could save future IO by staying in the cache) into free heap space.

(10) By Mangal Prajapati (V16be1p11) on 2022-01-31 09:09:21 in reply to 9 [link] [source]

So please reply me what i need to do to avoid restart issue ? Because i Know that when am using sqlite query my Device get restarted due to heap memory reach from 2000000 to 6000000.

I Hope you understand what i mean to say. Because any body will not get interested in device which get restarted on heap memory reach to 6000000.

Please help me my product has this only issue.

(11) By Gunter Hick (gunter_hick) on 2022-01-31 09:26:05 in reply to 10 [link] [source]

1) fix your memory leaks
2) use MEMSYS5

(12) By Larry Brasfield (larrybr) on 2022-01-31 11:05:28 in reply to 10 [link] [source]

I do not know why you have ignored Gunter's perfectly sound advice on the problem you are having. But just in case you need to see more than one responder telling you the same thing before heeding it: Fix your "memory leaks"a and study your options for controlling how SQLite in your application obtains memory and doles it out for use within the SQLite library itself.. In my opinion, it is likely that you will find the zero-malloc memory allocator useful, just as Gunter says. I would only qualify that advice to say that, if your system has malloc()/realloc()/free() already, and you have eliminated your memory leaks, you may not need to depart from SQLite's usual default allocator.

The first step is to cure those memory leaks. Without that done, it will not matter what else you do short of periodically terminating your application so that it can begin accumulating and wasting memory again. (Don't put effecting this solution on your resume.)

One more point: It is discourteous, and likely to get yourself into the "routinely ignored" category of forum participants to post the same problem under different thread titles. Please stop doing that; it's annoying and does not improve your prospects for getting an answer you can understand.

A last point: Gunter's responses have been clear, accurate and complete. So asking him to explain further, without indicating what parts of the previous reply puzzles you, is rude and a waste of time. How is he or anybody else to know what particular points are beyond your grasp? And if it is all beyond your grasp, you have come to the wrong place to get programming tutorials.

a. Do a web search on this term if you do not understand it.