Strange behavior for TARGET.EPOCSTACKSIZE

[JanuszNSG]

Hello to all. Right now I’m on finish stage in some reather big appliacation. Almost verything works fine, but… yeah always is some “but”.
Some task in app are realized by separate threads: downloading, parsing and storing in memory and disc data. Those data rather big, even 700k of JSON script. Sometime those threads crashes, every time in the same fragment of code:
if (reply->isReadable()) {
response = reply->readAll(); //nug here
}

“reply” is a QNetworkReply object (which as you can see – calling to „isReadable” exists and is valid).
Error messages – Panic, Reason 44 suggests there is no enough memory. HALData::EMemoryRAMFree allways returns value over 100 Mb (onb E7 and E8), so we trying to change stack sizde (as far as I know,, on Symbian Qthread object running with default stack size for app). And here is another problem, previous value for TARGET.EPOCSTACKSIZE was 0x1400 (~82K), on emulator if we set it to 0x20000 (~130Kb) treads stop crashing, but… (another) if we trying to debug/run app with settings:
TARGET.EPOCSTACKSIZE = 0x14000
We have crashes, but app works… till crash ofcouse.
With setting:
TARGET.EPOCSTACKSIZE = 0x28000
Application don’t run on the device.
If trying to build directly to device, after successful build and installing we receive error: Can’t run application – General OS related error.
If trying to install manually, work perfectly (app installed on device) but not start at all, w/o anny message.

Any ideas?

--- Ok I Found information: http://lists.macosforge.org/pipermai...er/143753.html
wich suggest, we cant change stack size over 0x14000, so must think other solution.... Help please

[jakoskin]

Hi 80KB is the maximum stack size what you can have and is the default for all Qt threads (QThread). Size limit is as you discovered is hardcoded in kernel and cannot be extended further.
The solution is obvious.. move stuff to heap.

Note that target.epocstacksize only affects the main thread of the application. Doesn't really matter though as they all are maxed out.

[JanuszNSG]

Ok, understand.
But after moving data buffers to main thread, I still receive error when trying read data form reply:

this->NetworkCaller->mainresponse = reply->readAll();

NetworkCaller is an object where data are originally stored, in main app thread.
Maybe I’m just too confused right now, to see own mistakes…

[danhicksbyron]

I doubt that stack size is at the root of your problem. Only if you're allocating large C++ arrays in the stack, or recurring deeply, would stack size be an issue. Large (growable) Qt objects are always allocated in two parts, with the large part in heap.

[JanuszNSG]

Have no other idea, Qthread was used to download and parse data form network - at start.
Now they responsible to accumulate data too (multiquery for one set of data) and saving them on disc with couple additional tasks.

As I wrote earlier - crash occurs when we retrieve data form QNetworkReply, and it happens only when JSON file are large (not always too). Eg. when reading triggered by user, crash not occurs, when data retrieved in batch - one after one - occurs mostly always.

So... have no clue what other could cause this problem.

[danhicksbyron]

Well, the first (and second and third) suspicion would be that you're running out of heap.

[JanuszNSG]

As Far As I know:
HALData::EMemoryRAMFree allways returns value over 100 Mb - and that's a memory avariable for heap.

[danhicksbyron]

The amount of free RAM is not the same as the amount of available heap. Not even close.