【寫在前面】近期參與到OEM項目中，目前主要是DLNA的項目維護與新feature實現。本系列博文主要記錄所修過的issues以及對DLNA stack的理解和分析，以便後來查閱。
------------------------------------------------------------------------------------------------------------------------------------
向Sharp BD upload m2ts文件時，如果屏幕鎖屏後導致WiFi斷開或者手動關掉WiFi，都會導致libdmc庫crash，必現。分析原因是：在向Sharp BD upload格式爲m2ts的媒體時，stack會輪詢向BD發送媒體數據和接收response。當WiFi鏈接斷開時，stack接收不到response，此時正確的處理是：拋出Error的錯誤並停止再向BD發送數據。但是之前stack中的處理是拋出Error並繼續發送了數據，由此造成了空指針異常並引起crash。
該bug強調一定是向sharp設備upload m2ts媒體，因爲這一case走的流程是CUploaderM2ts文件中的upload，該流程是stack爲sharp定製的。
=============================================================================
upload模塊分析：
Upnpstack_Export.cpp -----> TVUPNP_EnableUploader
Upnpstack_Export.cpp -----> TVUPNP_UploadFile
CUploadManager ------> GetUploader 獲取CUploaderBase子類的uploader對象
uploader對象調用各自的UploadFile方法
UploadFile方法中先通過DeviceCapabilityCheck檢查DMS允許上傳的文件類型，再通過ObjectCapabilityCheck方法判斷szParentId是否是“DLNA.ORG_AnyContainer”，當前stack僅支持上傳到DLNA.ORG_AnyContainer.
判斷完成後，通過SetState設置upload狀態m_State爲正在處理。
隨後啓動timer，並且將自己（子類的upload都是繼承了Task的）加入到TaskManager中（via AddToManager method）。
進入子類的DoRun方法（如果已重寫）進行輪詢，根據狀態判斷流程走向。