Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Hi,

I'm using an Audiovox CDM-8600 running on Verizon:

Software version T055VE2M01_4.235
Hardware TX-55C_Rev_02.

The device crashes while downloading tons of IWeb data, one ~2k item right after another. The crash is such that the screen shows up blank, except for this: "dsstcp.c 01313". I assume this means in that code some exception occurred.

Does anyone have experience with the CDM-8600 being fragile in the TCP layer?

I don't know what we could be doing wrong; no other handset I've tried has the same issue (8900, 4500, 4600, 6000/5450).

Should we put in a 50ms pause timer between requests to "give it a chance to rest"?

Our IWeb usage is pretty stupid, the most complex we do with it is to use some webopts: WEBOPT_CONNECTTIMEOUT, WEBOPT_STATUSHANDLER, WEBOPT_HEADERHANDLER, and WEBOPT_HANDLERDATA.

Memory levels seem fine at the time.

I've noticed also that the device cancels/ignores some of our requests...and that our retry-request logic is utilized a lot...which should not be the case. Maybe this is a symptom?

Any thoughts welcome! Cheers,
Nick

Update: it's line 01313 and not 133.
Also, increasing the timeout between starting new requests to 150ms from 10ms caused it to crash much quicker...oddly. Or maybe it's me.

Update: it's line 01313 and not 133.
Also, increasing the timeout between starting new requests to 150ms from 10ms caused it to crash much quicker...oddly. Or maybe it's me.

Update:
Now we're trying to release the IWeb itself in between transactions, and not just releasing the IWebRequest.
This seems to make the app less prone to the unexplained pauses (it shows 'X' or 'x' when it should be opening a new net connection!).
No crashes...yet. (crosses fingers)

Update:
Now we're trying to release the IWeb itself in between transactions, and not just releasing the IWebRequest.
This seems to make the app less prone to the unexplained pauses (it shows 'X' or 'x' when it should be opening a new net connection!).
No crashes...yet. (crosses fingers)

Update:
Well it crashes still.
After the WEBS_CONNECT and before the WEBS_SENDREQUEST...this is derived from the diagnostic WebOpt handler: WEBOPT_STATUSHANDLER.
I need more diagnostic info. I hope this is my bug.

Update:
Well it crashes still.
After the WEBS_CONNECT and before the WEBS_SENDREQUEST...this is derived from the diagnostic WebOpt handler: WEBOPT_STATUSHANDLER.
I need more diagnostic info. I hope this is my bug.

Previously we had seen such problem with apps. that had the following type of implementation for their network code :
#define someflag 1 // trying to use a binary semaphore
TransactionScheduler() {
ISHELL_SetTimer(..., with very small time gap, ) // calls TransactionScheduler
startTransaction()

startTransaction() {
if (someflag) {
someflag = 0;
// allocated necessary socket resources for transaction
// do socket transaction
...
...
...
}

TransactionCallBack() {
// when transaction complete
// release all necessary socket stuff
someflag = 1; // so that a new transaction can be started.

On removing the TransactionScheduler() and having something like ...
TransactionCallBack() {
// when transaction complete
// release all necessary socket stuff
ISHELL_SetTimer( ... to start the next transaction ...)

had solved the problem.
If you are still facing problems, can you attach source code for a sample app. that reproduces the problem so that we can investigate the issue further ?
Thanks

Previously we had seen such problem with apps. that had the following type of implementation for their network code :
#define someflag 1 // trying to use a binary semaphore
TransactionScheduler() {
ISHELL_SetTimer(..., with very small time gap, ) // calls TransactionScheduler
startTransaction()

startTransaction() {
if (someflag) {
someflag = 0;
// allocated necessary socket resources for transaction
// do socket transaction
...
...
...
}

TransactionCallBack() {
// when transaction complete
// release all necessary socket stuff
someflag = 1; // so that a new transaction can be started.

On removing the TransactionScheduler() and having something like ...
TransactionCallBack() {
// when transaction complete
// release all necessary socket stuff
ISHELL_SetTimer( ... to start the next transaction ...)

had solved the problem.
If you are still facing problems, can you attach source code for a sample app. that reproduces the problem so that we can investigate the issue further ?
Thanks

I've been working on a sample app to crash the phone (only the 8600 crashes...). I have had the app crash in as quick as 20 seconds, and as long as never. The app is attached.
When the app launches, it will display some purple rectangles.
Press RIGHT to start the test. You will see a lot of output drawn to the screen.
Press LEFT to clear the screen.
Press CLR or END to exit.
The does two things: the applet hits a webpage for a small file (< 2k), reads it, then repeats.
Number two, the applet has a timed ABORT callback which starts up 7 seconds after you press RIGHT. It will try to abort your request mid-stream. The repeat interval for this callback is random, up to 2.1 seconds.
I have tried to log to a file to see if any prior-conditions lead to crashes. I have not derived a combination of error codes or aborts instances. I included the last few lines from 8 reports where the app crashed inside the attached zip archive.
This app, with its particular set of timings, tends to crash the phone within 60 seconds, though I've seen it take 4 or 5 mins.
Please try it out, the .cpp, .h, .bid, and .mif file are all included.
Nick

I've been working on a sample app to crash the phone (only the 8600 crashes...). I have had the app crash in as quick as 20 seconds, and as long as never. The app is attached.
When the app launches, it will display some purple rectangles.
Press RIGHT to start the test. You will see a lot of output drawn to the screen.
Press LEFT to clear the screen.
Press CLR or END to exit.
The does two things: the applet hits a webpage for a small file (< 2k), reads it, then repeats.
Number two, the applet has a timed ABORT callback which starts up 7 seconds after you press RIGHT. It will try to abort your request mid-stream. The repeat interval for this callback is random, up to 2.1 seconds.
I have tried to log to a file to see if any prior-conditions lead to crashes. I have not derived a combination of error codes or aborts instances. I included the last few lines from 8 reports where the app crashed inside the attached zip archive.
This app, with its particular set of timings, tends to crash the phone within 60 seconds, though I've seen it take 4 or 5 mins.
Please try it out, the .cpp, .h, .bid, and .mif file are all included.
Nick

Bumping the "2100" where it says "smackdown" in the code to "1400" decreases the time it takes to crash to two-three minutes.

Bumping the "2100" where it says "smackdown" in the code to "1400" decreases the time it takes to crash to two-three minutes.

My crashing example BREW code seems correct, given what the 2.0 PDF SDK docs say, and what's posted on the Known Issues portion of the BREW site, and what's available here on this board. This code works on other Audiovox phones, and several LG phones.
This code doesn't use mutexes, as tamoghna suggested we avoid in the above reply.
It could be, in my personal opinion:
1) the phone has something wrong with it. Currently it can't receive phone calls, Verizon customer service is mystified and is willing to RMA the phone. Anytime I call it, the call goes through to someone else's voicemail box...more recently to a "this number has been disconnected".
2) a firmware bug
3) other..?

My crashing example BREW code seems correct, given what the 2.0 PDF SDK docs say, and what's posted on the Known Issues portion of the BREW site, and what's available here on this board. This code works on other Audiovox phones, and several LG phones.
This code doesn't use mutexes, as tamoghna suggested we avoid in the above reply.
It could be, in my personal opinion:
1) the phone has something wrong with it. Currently it can't receive phone calls, Verizon customer service is mystified and is willing to RMA the phone. Anytime I call it, the call goes through to someone else's voicemail box...more recently to a "this number has been disconnected".
2) a firmware bug
3) other..?

We have a core web transaction engine built on IWEB that also has serious problems on our 8600. On all other handsets we have used on I have never seen it crash. On the 8600 it often dies a horrible death in the oem layer.
It seems the network layer in the 8600 is fragile. If anyone has a network app running stable on the 8600 I would like to know. As it is now I am not sure how much time to invest in this problem given there may be no workaround and this is not a really high volume handset.

We have a core web transaction engine built on IWEB that also has serious problems on our 8600. On all other handsets we have used on I have never seen it crash. On the 8600 it often dies a horrible death in the oem layer.
It seems the network layer in the 8600 is fragile. If anyone has a network app running stable on the 8600 I would like to know. As it is now I am not sure how much time to invest in this problem given there may be no workaround and this is not a really high volume handset.

Your implementation of
void AnalyzeApp::WebTestCB(void *po) {
...
...
// check again in a moment
ISHELL_SetTimer(m_pApp->m_pIShell, 40, WebTestCB, m_pApp);

is comparable to the implementation I have described in my previous post and have recommended to avoid.
Please avoid the implementation where you "check again in a moment". Its not required. Set a timer to start the next data transaction only after the first one is complete. Additionally, you can comment out the timer which "aborts" the process.
After making these changes to your sample app., please re-check if you are still facing the problem.
Thanks,

Your implementation of
void AnalyzeApp::WebTestCB(void *po) {
...
...
// check again in a moment
ISHELL_SetTimer(m_pApp->m_pIShell, 40, WebTestCB, m_pApp);

is comparable to the implementation I have described in my previous post and have recommended to avoid.
Please avoid the implementation where you "check again in a moment". Its not required. Set a timer to start the next data transaction only after the first one is complete. Additionally, you can comment out the timer which "aborts" the process.
After making these changes to your sample app., please re-check if you are still facing the problem.
Thanks,

Tamoghna,
Thank you for the clarification and the analysis of my test application.
Removing the "check again in a moment" timer still results in a crash.
I have found [a fix? :) ] that the test application does NOT crash (20 minutes and no crash) when I remove the randomAbortCB function, avoiding prematurely terminating network requests.
Again, if I simply avoid releasing any IWeb resources while in the middle of a request then the test app does NOT crash. My 8600 crashes when I release my connection (IWEBRESP_Release(webResp)) while it's still processing the request/response.
I still get a crash in our production BREW app, hammering on the network, but with the change preventing it from closing any currently-running iweb requests.
Analyzing the suggestion of eliminating a "check again in a moment" code, the concept of a user-app scheduling a timeslice from the BREW OS means user-code is operating while networking code has requests in the air. My test code only calls the BREW ISHELL_SetTimer, IDISPLAY_DrawText, IDISPLAY_SetColor, and STRTOWSTR functions, none of which should interfere with the IWEB or INETMGR.
Also, asynchronous ISHELL_SetTimer usage is central to how our application operates. If the 8600 simply does not support user-application operation while networking then there should be a note made to the BDS saying so.
Given the apparent fix of requiring blocking on the IWEBRESP_Release(webResp), we cannot port our application to this phone without significant lag showing up to the user.
Our app involves the user panning across infinite maps, downloaded in real time, in the background. If we require each map be downloaded before we start another, then we are punish our users for panning up, allowing the app to begin download, then immediately panning down again, because they'll have to wait the 5-7 seconds for that last map to complete download.
Can you confirm that cancelling a web request mid-stream is an issue with the 8600?
Can you confirm also that the network is know to be fragile in other ways, as is evidenced by my unofficial experiment with our production app I mentioned above?
Thanks again for looking into this, and my code so thoroughly already,
Nick
[edit: I guess it's not too bad for the user. I hacked up our production app and the experience isn't terrible, just not what I would like. :p ]

Tamoghna,
Thank you for the clarification and the analysis of my test application.
Removing the "check again in a moment" timer still results in a crash.
I have found [a fix? :) ] that the test application does NOT crash (20 minutes and no crash) when I remove the randomAbortCB function, avoiding prematurely terminating network requests.
Again, if I simply avoid releasing any IWeb resources while in the middle of a request then the test app does NOT crash. My 8600 crashes when I release my connection (IWEBRESP_Release(webResp)) while it's still processing the request/response.
I still get a crash in our production BREW app, hammering on the network, but with the change preventing it from closing any currently-running iweb requests.
Analyzing the suggestion of eliminating a "check again in a moment" code, the concept of a user-app scheduling a timeslice from the BREW OS means user-code is operating while networking code has requests in the air. My test code only calls the BREW ISHELL_SetTimer, IDISPLAY_DrawText, IDISPLAY_SetColor, and STRTOWSTR functions, none of which should interfere with the IWEB or INETMGR.
Also, asynchronous ISHELL_SetTimer usage is central to how our application operates. If the 8600 simply does not support user-application operation while networking then there should be a note made to the BDS saying so.
Given the apparent fix of requiring blocking on the IWEBRESP_Release(webResp), we cannot port our application to this phone without significant lag showing up to the user.
Our app involves the user panning across infinite maps, downloaded in real time, in the background. If we require each map be downloaded before we start another, then we are punish our users for panning up, allowing the app to begin download, then immediately panning down again, because they'll have to wait the 5-7 seconds for that last map to complete download.
Can you confirm that cancelling a web request mid-stream is an issue with the 8600?
Can you confirm also that the network is know to be fragile in other ways, as is evidenced by my unofficial experiment with our production app I mentioned above?
Thanks again for looking into this, and my code so thoroughly already,
Nick
[edit: I guess it's not too bad for the user. I hacked up our production app and the experience isn't terrible, just not what I would like. :p ]

Hmm...bad deal.
Thank you very much for putting in your $0.02, this affirmation is very welcome to me.
I really do think the idea of not dropping a web request mid-stream, instead relying upon the CONNECTTIMEOUT webopt is the fix.
-Nick
cistearns wrote:We have a core web transaction engine built on IWEB that also has serious problems on our 8600. On all other handsets we have used on I have never seen it crash. On the 8600 it often dies a horrible death in the oem layer.
It seems the network layer in the 8600 is fragile. If anyone has a network app running stable on the 8600 I would like to know. As it is now I am not sure how much time to invest in this problem given there may be no workaround and this is not a really high volume handset.

Hmm...bad deal.
Thank you very much for putting in your $0.02, this affirmation is very welcome to me.
I really do think the idea of not dropping a web request mid-stream, instead relying upon the CONNECTTIMEOUT webopt is the fix.
-Nick
cistearns wrote:We have a core web transaction engine built on IWEB that also has serious problems on our 8600. On all other handsets we have used on I have never seen it crash. On the 8600 it often dies a horrible death in the oem layer.
It seems the network layer in the 8600 is fragile. If anyone has a network app running stable on the 8600 I would like to know. As it is now I am not sure how much time to invest in this problem given there may be no workaround and this is not a really high volume handset.

Apparantly a handful of J2ME phones crash when cancelling in-the-air network transactions...so says a programmer pal.

Apparantly a handful of J2ME phones crash when cancelling in-the-air network transactions...so says a programmer pal.

While it is possible to not drop a web request mid-stream under normal operations, this can't be a complete solution. What about when the user hits CLR or even worse END. When END is hit you can't sit around waiting fo the connection to timeout.
If it truly is the case that canceling a connection causes the crash then I don't see how we can expect to have any network enabled app on this phone.
(At least this doesn't seem to be a high sales volume handset.)
Charles

While it is possible to not drop a web request mid-stream under normal operations, this can't be a complete solution. What about when the user hits CLR or even worse END. When END is hit you can't sit around waiting fo the connection to timeout.
If it truly is the case that canceling a connection causes the crash then I don't see how we can expect to have any network enabled app on this phone.
(At least this doesn't seem to be a high sales volume handset.)
Charles

Can you confirm that cancelling a web request mid-stream is an issue with the 8600?
Cancelling a web request mid-stream is not the issue. The issue is placing your app. in a situation when it is trying close/release as well as open/allocate socket resources within a *very short* period of time due to type of implementation you have in your app.
Again, implementation of data transaction should be as I have explained before ...i.e start subsequent transaction (socket resouce allocation) only after the previous one has been completed. Do not put it in "tight loop" i.e. "check again in a moment" scenario. A END key or CLR key in the middle of a data transaction will not cause this problem. And certainly, an app. will not have any problem handling user responses while waiting for callbacks to fire.
I would suggest you to try chaning your implementation, and then use END or CLR key while doing data transaction to see if it at all crashes your handset. If it does, please post your apps. source code.

Can you confirm that cancelling a web request mid-stream is an issue with the 8600?
Cancelling a web request mid-stream is not the issue. The issue is placing your app. in a situation when it is trying close/release as well as open/allocate socket resources within a *very short* period of time due to type of implementation you have in your app.
Again, implementation of data transaction should be as I have explained before ...i.e start subsequent transaction (socket resouce allocation) only after the previous one has been completed. Do not put it in "tight loop" i.e. "check again in a moment" scenario. A END key or CLR key in the middle of a data transaction will not cause this problem. And certainly, an app. will not have any problem handling user responses while waiting for callbacks to fire.
I would suggest you to try chaning your implementation, and then use END or CLR key while doing data transaction to see if it at all crashes your handset. If it does, please post your apps. source code.

When you say a "very short time", what scale are we talking here?
How long of a delay should be put in place between closing transactions and opening new ones?
250ms?
1 sec?
Also is this a fragile area on all handsets and we have just been lucky - or is this point of fragility strictly on the 8600.
Thanks,
Charles

When you say a "very short time", what scale are we talking here?
How long of a delay should be put in place between closing transactions and opening new ones?
250ms?
1 sec?
Also is this a fragile area on all handsets and we have just been lucky - or is this point of fragility strictly on the 8600.
Thanks,
Charles

I am able to reproduce this error (dsstcp.c) and crash on both KE47 and CDM8600!
I haven't been able to fix this yet but the error seems to be related to repeatedly making IWEB network calls, one after another, to download small files remotely.
Any ideas?

I am able to reproduce this error (dsstcp.c) and crash on both KE47 and CDM8600!
I haven't been able to fix this yet but the error seems to be related to repeatedly making IWEB network calls, one after another, to download small files remotely.
Any ideas?

Hey thanks for checking this out! Cool that it shows up on the slider too...
If I understand Tamoghna right, we need to pause before starting a new connection.
I don't yet understand the idea about scheduling the transaction however, I don't see how using a mutex versus using a chained callback makes a difference...writing to memory??? I just don't see the difference.
I do believe that he indicated slowing down the net transactions a bit would help...so if we put a sleep(400 ms) between close & open, then perhaps that'd fix it.
jsu800 wrote:I am able to reproduce this error (dsstcp.c) and crash on both KE47 and CDM8600!
I haven't been able to fix this yet but the error seems to be related to repeatedly making IWEB network calls, one after another, to download small files remotely.
Any ideas?

Hey thanks for checking this out! Cool that it shows up on the slider too...
If I understand Tamoghna right, we need to pause before starting a new connection.
I don't yet understand the idea about scheduling the transaction however, I don't see how using a mutex versus using a chained callback makes a difference...writing to memory??? I just don't see the difference.
I do believe that he indicated slowing down the net transactions a bit would help...so if we put a sleep(400 ms) between close & open, then perhaps that'd fix it.
jsu800 wrote:I am able to reproduce this error (dsstcp.c) and crash on both KE47 and CDM8600!
I haven't been able to fix this yet but the error seems to be related to repeatedly making IWEB network calls, one after another, to download small files remotely.
Any ideas?

I think we should add an X amount of delay in ms btwn close/release & open/allocate in IWEB.
Also try not to release IWEB (but iwebresp and some callback buffers) and CALLBACK_Cancel() until the very end, i.e., in the destructor of your class.
You might have already done that but just throwing something out for you to consider, and see what happens.

I think we should add an X amount of delay in ms btwn close/release & open/allocate in IWEB.
Also try not to release IWEB (but iwebresp and some callback buffers) and CALLBACK_Cancel() until the very end, i.e., in the destructor of your class.
You might have already done that but just throwing something out for you to consider, and see what happens.

nrichards wrote:Hey thanks for checking this out! Cool that it shows up on the slider too...
If I understand Tamoghna right, we need to pause before starting a new connection.
I don't yet understand the idea about scheduling the transaction however, I don't see how using a mutex versus using a chained callback makes a difference...writing to memory??? I just don't see the difference.
I do believe that he indicated slowing down the net transactions a bit would help...so if we put a sleep(400 ms) between close & open, then perhaps that'd fix it.
Scheduling the transactions, like you have in your implementation or in the case of using a mutex, causes the application to have unnecessary events added to the event queue. Generating/processing/dropping unncessary events is not a good design. You dont require to put a sleep. What you can do is, after a web transaction completed, schedule a timer for ~ 150 to 200 ms for starting the next transaction. This should not cause any problems on the handset.

nrichards wrote:Hey thanks for checking this out! Cool that it shows up on the slider too...
If I understand Tamoghna right, we need to pause before starting a new connection.
I don't yet understand the idea about scheduling the transaction however, I don't see how using a mutex versus using a chained callback makes a difference...writing to memory??? I just don't see the difference.
I do believe that he indicated slowing down the net transactions a bit would help...so if we put a sleep(400 ms) between close & open, then perhaps that'd fix it.
Scheduling the transactions, like you have in your implementation or in the case of using a mutex, causes the application to have unnecessary events added to the event queue. Generating/processing/dropping unncessary events is not a good design. You dont require to put a sleep. What you can do is, after a web transaction completed, schedule a timer for ~ 150 to 200 ms for starting the next transaction. This should not cause any problems on the handset.

We had none of the asychronous timer callbacks like you mentioned in our codes and the handset (8600) still crashed. We were able to crash the handset during IWEB connection, after downloading and saving a lot of music ring tones to the file system.
In every step of the way we made sure that we allow for a few seconds delay between the last release() and the next open(). Throughout our codes we only deallocate IWEBResp and other necessary mem stream buffers in release() and put IWEB_GetResponse() in open(). IWEB and other CALLBACK objects are positioned in constructor of the class we used, so these objects got initialized only once, and deleted in the destructor of the class.
Could it be that the 8600's net layer becomes extra fraigile after the file system is loaded with stuff or while the system is downloading and saving a lot of files at the same time? Again, there is absolutely a delay between each close()/release() and init()/open().

We had none of the asychronous timer callbacks like you mentioned in our codes and the handset (8600) still crashed. We were able to crash the handset during IWEB connection, after downloading and saving a lot of music ring tones to the file system.
In every step of the way we made sure that we allow for a few seconds delay between the last release() and the next open(). Throughout our codes we only deallocate IWEBResp and other necessary mem stream buffers in release() and put IWEB_GetResponse() in open(). IWEB and other CALLBACK objects are positioned in constructor of the class we used, so these objects got initialized only once, and deleted in the destructor of the class.
Could it be that the 8600's net layer becomes extra fraigile after the file system is loaded with stuff or while the system is downloading and saving a lot of files at the same time? Again, there is absolutely a delay between each close()/release() and init()/open().

jsu800 wrote:
Could it be that the 8600's net layer becomes extra fraigile after the file system is loaded with stuff or while the system is downloading and saving a lot of files at the same time? Again, there is absolutely a delay between each close()/release() and init()/open().
That should not be the case. However, I would suggest you to post sample app. which re-produces the problem and we can investigate further.
Thanks

jsu800 wrote:
Could it be that the 8600's net layer becomes extra fraigile after the file system is loaded with stuff or while the system is downloading and saving a lot of files at the same time? Again, there is absolutely a delay between each close()/release() and init()/open().
That should not be the case. However, I would suggest you to post sample app. which re-produces the problem and we can investigate further.
Thanks

JSU 800!
Thanks for the pointer, this is helpful.
Re the ringtone downloading fragility...there's a Known Issue regarding bricking the device :eek: after downloading 100+ ringtones.... This is mentioned on the BREW extranet phone info internal site.
jsu800 wrote:Could it be that the 8600's net layer becomes extra fraigile after the file system is loaded with stuff or while the system is downloading and saving a lot of files at the same time? Again, there is absolutely a delay between each close()/release() and init()/open().

JSU 800!
Thanks for the pointer, this is helpful.
Re the ringtone downloading fragility...there's a Known Issue regarding bricking the device :eek: after downloading 100+ ringtones.... This is mentioned on the BREW extranet phone info internal site.
jsu800 wrote:Could it be that the 8600's net layer becomes extra fraigile after the file system is loaded with stuff or while the system is downloading and saving a lot of files at the same time? Again, there is absolutely a delay between each close()/release() and init()/open().

Did you mean Knonw Issues for CDM8600? Where did you see the issue with respect to downloading 100+ ringtones? Thanks

Did you mean Knonw Issues for CDM8600? Where did you see the issue with respect to downloading 100+ ringtones? Thanks

HMM! I thought I saw it earlier.
Perhaps I saw it for the 8410, hmm...checking...nope!
There are currently zero "known issues" for the 8600, listed on the website:
https://brewx.qualcomm.com/bws/content/docx/devices/docs/curitel/known_i...
jsu800 wrote:Did you mean Knonw Issues for CDM8600? Where did you see the issue with respect to downloading 100+ ringtones? Thanks
Sorry JSU, I must have been mistaken!

HMM! I thought I saw it earlier.
Perhaps I saw it for the 8410, hmm...checking...nope!
There are currently zero "known issues" for the 8600, listed on the website:
https://brewx.qualcomm.com/bws/content/docx/devices/docs/curitel/known_i...
jsu800 wrote:Did you mean Knonw Issues for CDM8600? Where did you see the issue with respect to downloading 100+ ringtones? Thanks
Sorry JSU, I must have been mistaken!

That's an issue that appeared on handsets for another OEM, and involved deleting 100+ ringers.

That's an issue that appeared on handsets for another OEM, and involved deleting 100+ ringers.

Doh! Thanks for that clarification.
mohlendo wrote:That's an issue that appeared on handsets for another OEM, and involved deleting 100+ ringers.

Doh! Thanks for that clarification.
mohlendo wrote:That's an issue that appeared on handsets for another OEM, and involved deleting 100+ ringers.

I've had this problem occur sometimes on the 1st IWEB connection after it finishes. Although it usually does occur after several tries. The next connection isn't even immediately right after the other. I've tried waiting several seconds before doing another connection and the same crash occurs.

I've had this problem occur sometimes on the 1st IWEB connection after it finishes. Although it usually does occur after several tries. The next connection isn't even immediately right after the other. I've tried waiting several seconds before doing another connection and the same crash occurs.

More info.... it seems to happen once in a while AFTER a connection finishes and I try to do a clean up. It doesn't always crash but its always seems to happen during the clean up state when the connection is done. I've tried delaying the clean up by 10 secs and it seems to crash less but still does once in a while.
NetHttp* pNetHttp = (NetHttp *)user;
if (pNetHttp->Callback.pfnCancel != NULL)
{
CALLBACK_Cancel(&pNetHttp->Callback);
}
if (pNetHttp->pIWebResp != NULL)
{
IWEBRESP_Release(pNetHttp->pIWebResp);
pNetHttp->pIWebResp = NULL;
}
if (pNetHttp->pIWeb != NULL)
{
IWEB_Release(pNetHttp->pIWeb);
pNetHttp->pIWeb = NULL;
}
pNetHttp->packageSize = 0;

More info.... it seems to happen once in a while AFTER a connection finishes and I try to do a clean up. It doesn't always crash but its always seems to happen during the clean up state when the connection is done. I've tried delaying the clean up by 10 secs and it seems to crash less but still does once in a while.
NetHttp* pNetHttp = (NetHttp *)user;
if (pNetHttp->Callback.pfnCancel != NULL)
{
CALLBACK_Cancel(&pNetHttp->Callback);
}
if (pNetHttp->pIWebResp != NULL)
{
IWEBRESP_Release(pNetHttp->pIWebResp);
pNetHttp->pIWebResp = NULL;
}
if (pNetHttp->pIWeb != NULL)
{
IWEB_Release(pNetHttp->pIWeb);
pNetHttp->pIWeb = NULL;
}
pNetHttp->packageSize = 0;

Was there ever a resolution to this problem?
Would it be waived as a known issue?

Was there ever a resolution to this problem?
Would it be waived as a known issue?

I've heard nothing about this. No confessions from any industry reps... :p Nor duplication info from the QC guys ... no matter.
I suggest replacing your HTTP layer with a custom one that sits on top of the socket layer. It shouldn't be a complex layer, just something that opens, sends, receives, closes.
It will take much less time to write this than to workaround whatever issue is wrong with the Audiovox CDM-8600.
:confused: Nick :confused:

I've heard nothing about this. No confessions from any industry reps... :p Nor duplication info from the QC guys ... no matter.
I suggest replacing your HTTP layer with a custom one that sits on top of the socket layer. It shouldn't be a complex layer, just something that opens, sends, receives, closes.
It will take much less time to write this than to workaround whatever issue is wrong with the Audiovox CDM-8600.
:confused: Nick :confused:

Update: Doh! looks like it still happens, abeit less frequently. =(
It should be noted that replacing your implementation with an ISocket implementation will NOT fix the issue as I was getting the exact same error message with my ISocket implementation.
Taking a cue from the first few ideas, I tried adding a delay between network requests. Adding 2 seconds between requests didn't work initially. However, once I made sure to release the ISocket and cancel any callbacks BEFORE the delay, it worked fine. The timeline is somewhat as follows:
-get ISocket
-do network transaction
-release ISocket
-wait 2 seconds
-get ISocket...etc
My app has room for a 2 second wait in between requests. If you experiment, I'm sure 2 seconds isn't the smallest amount of time you have to wait to be safe.
I never got this issue with IWeb, but we've long since thrown that interface out the window due to it's instability issues. HTTP is very simple and easy enough to implement by hand. Hopefully this information saves someone some time down the road. :)

Update: Doh! looks like it still happens, abeit less frequently. =(
It should be noted that replacing your implementation with an ISocket implementation will NOT fix the issue as I was getting the exact same error message with my ISocket implementation.
Taking a cue from the first few ideas, I tried adding a delay between network requests. Adding 2 seconds between requests didn't work initially. However, once I made sure to release the ISocket and cancel any callbacks BEFORE the delay, it worked fine. The timeline is somewhat as follows:
-get ISocket
-do network transaction
-release ISocket
-wait 2 seconds
-get ISocket...etc
My app has room for a 2 second wait in between requests. If you experiment, I'm sure 2 seconds isn't the smallest amount of time you have to wait to be safe.
I never got this issue with IWeb, but we've long since thrown that interface out the window due to it's instability issues. HTTP is very simple and easy enough to implement by hand. Hopefully this information saves someone some time down the road. :)