From rajesh.rathinasamy at nokia.com Fri May 18 13:53:30 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Fri May 18 14:13:41 2007
Subject: [Filesystem-dev] CR: Detection of MMC Card removal during playback
when Symbian data source is used
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
Index: ihxmmfdatasource.h
===================================================================
RCS file: /cvsroot/common/include/ihxmmfdatasource.h,v
retrieving revision 1.1.2.1
diff -w -u -b -r1.1.2.1 ihxmmfdatasource.h
--- ihxmmfdatasource.h 19 Sep 2006 23:16:12 -0000 1.1.2.1
+++ ihxmmfdatasource.h 17 May 2007 18:24:16 -0000
@@ -122,6 +122,9 @@
INT32 &ulValue) PURE;
STDMETHOD(GetSize) (THIS_ UINT32 &ulSize) PURE;
+
+ STDMETHOD(GetLastError) (THIS_) PURE;
+
};
#endif // _IHXMMFDATASOURCE_H_
Index: hxdatasource.cpp
===================================================================
RCS file: /cvsroot/common/fileio/hxdatasource.cpp,v
retrieving revision 1.1.2.1
diff -w -u -b -r1.1.2.1 hxdatasource.cpp
--- hxdatasource.cpp 19 Sep 2006 21:05:57 -0000 1.1.2.1
+++ hxdatasource.cpp 17 May 2007 18:25:30 -0000
@@ -58,6 +58,7 @@
CHXDataSource::CHXDataSource():
m_ulRefCount(0)
,m_ulPosition(0)
+ ,m_ulLastError(HXR_OK)
,m_pRequest(NULL)
{
}
@@ -182,3 +183,7 @@
return HXR_FAIL;
}
+STDMETHODIMP CHXDataSource::GetLastError()
+{
+ return m_ulLastError;
+}
Index: platform/symbian/hxdatasource_ccontent.cpp
===================================================================
RCS file: /cvsroot/common/fileio/platform/symbian/hxdatasource_ccontent.cpp,v
retrieving revision 1.1.2.1
diff -w -u -b -r1.1.2.1 hxdatasource_ccontent.cpp
--- platform/symbian/hxdatasource_ccontent.cpp 19 Sep 2006 21:10:10 -0000 1.1.2.1
+++ platform/symbian/hxdatasource_ccontent.cpp 17 May 2007 18:25:30 -0000
@@ -168,6 +168,7 @@
else
{
bytesRead = 0;
+ SetLastError(HXR_READ_ERROR);
HXLOGL1(HXLOG_FILE, "CHXDataSourceCContent::Read error=%d", err);
}
@@ -178,7 +179,7 @@
UINT32 CHXDataSourceCContent::Write(
void *pBuf, ULONG32 size, ULONG32 count)
{
-
+ SetLastError(HXR_NOTIMPL);
HX_ASSERT("CHXDataSourceCContent::Write" == NULL);
return 0;
}
@@ -239,6 +240,7 @@
else
{
hxr = HXR_FAIL;
+ SetLastError(hxr);
}
return hxr;
}
Index: platform/symbian/hxdatasource_descriptor.cpp
===================================================================
RCS file: /cvsroot/common/fileio/platform/symbian/hxdatasource_descriptor.cpp,v
retrieving revision 1.1.2.1
diff -w -u -b -r1.1.2.1 hxdatasource_descriptor.cpp
--- platform/symbian/hxdatasource_descriptor.cpp 19 Sep 2006 21:10:10 -0000 1.1.2.1
+++ platform/symbian/hxdatasource_descriptor.cpp 17 May 2007 18:25:30 -0000
@@ -111,6 +111,7 @@
if(requestSize <= 0)
{
+ SetLastError(HXR_READ_ERROR);
return 0;
}
@@ -126,7 +127,7 @@
UINT32 CHXDataSourceDescriptor::Write(
void *pBuf, ULONG32 size, ULONG32 count)
{
-
+ SetLastError(HXR_NOTIMPL);
HX_ASSERT("CHXDataSourceDescriptor::WriteL" == NULL);
return 0;
}
Index: platform/symbian/hxdatasourcemmfclip.cpp
===================================================================
RCS file: /cvsroot/common/fileio/platform/symbian/hxdatasourcemmfclip.cpp,v
retrieving revision 1.1.2.3
diff -w -u -b -r1.1.2.3 hxdatasourcemmfclip.cpp
--- platform/symbian/hxdatasourcemmfclip.cpp 27 Mar 2007 14:57:52 -0000 1.1.2.3
+++ platform/symbian/hxdatasourcemmfclip.cpp 17 May 2007 18:25:30 -0000
@@ -119,6 +119,8 @@
if(error != KErrNone)
{
HXLOGL1(HXLOG_FILE, "CHXDataSourceMMFClip::Read error=%d", error);
+ SetLastError(HXR_READ_ERROR);
+ retVal = 0;
}
return retVal;
@@ -135,6 +137,7 @@
if(error != KErrNone)
{
HXLOGL1(HXLOG_FILE, "CHXDataSourceMMFClip::Write error=%d", error);
+ SetLastError(HXR_WRITE_ERROR);
}
return retVal;
Index: pub/hxdatasource.h
===================================================================
RCS file: /cvsroot/common/fileio/pub/hxdatasource.h,v
retrieving revision 1.1.2.1
diff -w -u -b -r1.1.2.1 hxdatasource.h
--- pub/hxdatasource.h 19 Sep 2006 21:06:26 -0000 1.1.2.1
+++ pub/hxdatasource.h 17 May 2007 18:25:30 -0000
@@ -83,10 +83,15 @@
virtual UINT32 Read(THIS_ void *, ULONG32 size, ULONG32 count) PURE;
virtual UINT32 Write(THIS_ void *, ULONG32 size, ULONG32 count) PURE;
STDMETHOD(GetSize) (THIS_ UINT32 &ulSize) PURE;
+ STDMETHOD(GetLastError) (THIS_);
+
+protected:
+ inline void SetLastError(HX_RESULT lErr) {m_ulLastError = lErr;}
protected:
ULONG32 m_ulRefCount;
ULONG32 m_ulPosition; // current offset for the data
+ UINT32 m_ulLastError;
IHXRequest* m_pRequest;
};
Index: audiocontroller/installMMF.pcf
===================================================================
RCS file: /cvsroot/clientapps/symbianMmf/audiocontroller/installMMF.pcf,v
retrieving revision 1.1.2.1
diff -w -u -b -r1.1.2.1 installMMF.pcf
--- audiocontroller/installMMF.pcf 8 Sep 2006 19:06:47 -0000 1.1.2.1
+++ audiocontroller/installMMF.pcf 17 May 2007 22:02:27 -0000
@@ -168,7 +168,9 @@
'dmp4' : 'datatype_dist/rm/video/codec/g2mp4combo/dmp4.dll',
'log' : 'common/log/logsystem/[target]/log.dll',
'logobserverfile' : 'common/log/logobserver/[target]/logobserverfile.dll',
- 'arma' : 'datatype/mp4/audio/mdf/[target]/arma.dll' }
+ 'arma' : 'datatype/mp4/audio/mdf/[target]/arma.dll',
+ 'hxmetadataeng' : 'datatype/xps/fileformat/[target]/hxmetadataeng.dll'
+}
#
# some helpers to reduce clutter...
@@ -201,6 +203,8 @@
# always add client core dll
Add('clntcore')
+Add('hxmetadataeng')
+
if project.IsDefined("HELIX_FEATURE_PLAYBACK_LOCAL"):
Add('smplfsys')
Index: videocontroller/installMMF.pcf
===================================================================
RCS file: /cvsroot/clientapps/symbianMmf/videocontroller/installMMF.pcf,v
retrieving revision 1.5.2.13
diff -w -u -b -r1.5.2.13 installMMF.pcf
--- videocontroller/installMMF.pcf 4 Oct 2006 15:08:26 -0000 1.5.2.13
+++ videocontroller/installMMF.pcf 17 May 2007 22:02:27 -0000
@@ -170,7 +170,8 @@
'logobserverfile' : 'common/log/logobserver/[target]/logobserverfile.dll',
'arma' : 'datatype/mp4/audio/mdf/[target]/arma.dll',
'progdownfs' : 'filesystem/progdown/[target]/progdownfs.dll',
- 'XPSFileFormat' : 'datatype/xps/fileformat/[target]/XPSFileFormat.dll'
+ 'XPSFileFormat' : 'datatype/xps/fileformat/[target]/XPSFileFormat.dll',
+ 'hxmetadataeng' : 'datatype/xps/fileformat/[target]/hxmetadataeng.dll'
}
@@ -209,6 +210,7 @@
Add('progdownfs')
Add('XPSFileFormat')
+Add('hxmetadataeng')
if project.IsDefined("HELIX_FEATURE_PLAYBACK_LOCAL"):
Index: platform/symbian/pdfileobj.cpp
===================================================================
RCS file: /cvsroot/filesystem/progdown/platform/symbian/pdfileobj.cpp,v
retrieving revision 1.1.1.1.2.4
diff -w -u -b -r1.1.1.1.2.4 pdfileobj.cpp
--- platform/symbian/pdfileobj.cpp 18 Apr 2007 18:03:25 -0000 1.1.1.1.2.4
+++ platform/symbian/pdfileobj.cpp 18 May 2007 19:07:07 -0000
@@ -201,12 +201,16 @@
if(m_ulByteOffset + byteCount <= ulFileSize)
{
actualCount = DoRead(pBuffer);
+ if(IsReadError())
+ {
+ result = HXR_READ_ERROR;
+ }
}
-
HXLOGL4(HXLOG_FILE,
"CHXPDFileObject::DoReadLoopEx requested=%lu actual=%lu filesize=%lu",
byteCount, actualCount, ulFileSize);
-
+ if(SUCCEEDED(result))
+ {
if(actualCount < byteCount &&
!m_pDownloadObserver->IsDownloadComplete())
{
@@ -258,6 +262,12 @@
result = DoReadDone(readResult, pBuffer);
}
}
+ } // End of if(SUCCEEDED(result))
+ else
+ {
+ HX_RELEASE(pBuffer);
+ ReadDoneError(HXR_READ_ERROR);
+ }
return result;
}
@@ -423,12 +433,18 @@
if(m_ulByteOffset + m_ulRetryByteCount <= ulFileSize )
{
actualCount = DoRead(m_pRetryReadBuffer);
+ if(IsReadError())
+ {
+ result = HXR_READ_ERROR;
+ }
}
HXLOGL2(HXLOG_FILE,
"CHXPDFileObject::RetryRead requested=%lu actual=%lu filesize=%lu numRetries=%lu/%lu",
m_ulRetryByteCount, actualCount, ulFileSize, m_ulNumRetries, m_ulMaxRetries);
+ if(SUCCEEDED(result))
+ {
if(actualCount < m_ulRetryByteCount &&
!m_pDownloadObserver->IsDownloadComplete())
{
@@ -478,4 +494,12 @@
}
}
}
+ else
+ {
+ HX_RELEASE(m_pRetryReadBuffer);
+ ReadDoneError(HXR_READ_ERROR);
+ }
+
+ return;
+}
Index: mini/minifileobj.cpp
===================================================================
RCS file: /cvsroot/filesystem/local/mini/minifileobj.cpp,v
retrieving revision 1.23.2.2
diff -w -u -b -r1.23.2.2 minifileobj.cpp
--- mini/minifileobj.cpp 18 Apr 2007 17:56:56 -0000 1.23.2.2
+++ mini/minifileobj.cpp 18 May 2007 19:07:44 -0000
@@ -639,7 +639,7 @@
UINT32 actualCount = DoRead(pBuffer);
- if (m_pFile && ferror(m_pFile))
+ if(IsReadError())
{
HX_RELEASE(pBuffer);
ReadDoneError(HXR_READ_ERROR);
@@ -741,6 +741,20 @@
m_pFileResponse->ReadDone(theError, NULL);
}
+HXBOOL CHXMiniFileObject::IsReadError()
+{
+ HXBOOL bError = FALSE;
+
+#if defined(HELIX_FEATURE_MMF_DATASOURCE)
+ if(m_pDataSource && FAILED(m_pDataSource->GetLastError()) )
+#else
+ if (m_pFile && ferror(m_pFile))
+#endif
+ {
+ bError = TRUE;
+ }
+ return bError;
+}
/****************************************************************************
* IHXFileObject::Write
Index: mini/minifileobj.h
===================================================================
RCS file: /cvsroot/filesystem/local/mini/minifileobj.h,v
retrieving revision 1.6.2.1
diff -w -u -b -r1.6.2.1 minifileobj.h
--- mini/minifileobj.h 24 Aug 2006 20:15:01 -0000 1.6.2.1
+++ mini/minifileobj.h 18 May 2007 19:07:44 -0000
@@ -186,6 +186,8 @@
STDMETHOD_(UINT32, DoRead ) (THIS_ IHXBuffer* pBuffer);
STDMETHOD(DoReadDone ) (THIS_ HX_RESULT readResult, IHXBuffer* pBuffer);
STDMETHOD_(void, ReadDoneError ) (THIS_ HX_RESULT theError);
+
+ HXBOOL IsReadError();
};
#endif /* _MINIFILEOBJ_H_ */
From gwright at real.com Mon May 21 09:48:55 2007
From: gwright at real.com (Greg Wright)
Date: Mon May 21 10:07:07 2007
Subject: [Filesystem-dev] CR: Detection of MMC Card removal during playback
when Symbian data source is used
In-Reply-To:
References:
Message-ID: <4651CD77.80106@real.com>
Looks good.
--greg.
rajesh.rathinasamy@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this code
> under said agreement."
>
> Modified by: rajesh.rathinasamy@nokia.com
>
> Reviewed by:
>
> Date: 17-May-2007
>
> Project: SymbianMmf
>
> ErrorId: ETZG-732BAQ
>
> Synopsis: Detection of MMC Card removal during playback when
> Symbian data source is used
>
> MMC card removal during playout results in read error which was
> not handled. Added a new API to datasource interface similar to
> ferror(). Only symbianMMf uses the data source interface now, so adding
> a new interface does not have any impact on other platforms.
>
> Also updated the install pcf file to include meta data dll to
> the video and audio controller package files.
>
>
> Root Cause of the problem: Implementation
>
> Files Modified:
> common/include/ihxmmfdatasource.h
> common/fileio/hxdatasource.cpp
> common/fileio/platform/symbian/hxdatasource_ccontent.cpp
> common/fileio/platform/symbian/hxdatasource_descriptor.cpp
> common/fileio/platform/symbian/hxdatasourcemmfclip.cpp
> common/fileio/pub/hxdatasource.h
> filesystem/local/mini/minifileobj.cpp
> filesystem/local/mini/minifileobj.h
> filesystem/progdown/platform/symbian/pdfileobj.cpp
> clientapps/symbianMmf/audiocontroller/installMMF.pcf
> clientapps/symbianMmf/videocontroller/installMMF.pcf
>
>
> Image Size and Heap Use impact: no major impact
>
> Module Release testing (STIF) : Passed.
>
> Test case(s) Added : No.
>
> Memory leak check performed : Yes. No new leaks introduced.
>
> Platforms and Profiles Build Verified:
> helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5,winscw
>
> Branch: Head & 210CayS
> <>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Filesystem-dev mailing list
> Filesystem-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
From rajesh.rathinasamy at nokia.com Tue May 22 08:00:37 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Tue May 22 08:18:41 2007
Subject: [Filesystem-dev] CR: Detection of MMC Card removal during
playback when Symbian data source is used
In-Reply-To: <4651CD77.80106@real.com>
References:
<4651CD77.80106@real.com>
Message-ID:
Thanks Greg !
The changes have been checked into Head and 210CayS.
- Rajesh.
>-----Original Message-----
>From: ext Greg Wright [mailto:gwright@real.com]
>Sent: Monday, May 21, 2007 11:49 AM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas)
>Cc: common-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
>Subject: Re: [Filesystem-dev] CR: Detection of MMC Card
>removal during playback when Symbian data source is used
>
>Looks good.
>
>--greg.
>
>
>rajesh.rathinasamy@nokia.com wrote:
>> "Nokia submits this code under the terms of a commercial
>contribution
>> agreement with RealNetworks, and I am authorized to contribute this
>> code under said agreement."
>>
>> Modified by: rajesh.rathinasamy@nokia.com
>>
>> Reviewed by:
>>
>> Date: 17-May-2007
>>
>> Project: SymbianMmf
>>
>> ErrorId: ETZG-732BAQ
>>
>> Synopsis: Detection of MMC Card removal during
>playback when Symbian
>> data source is used
>>
>> MMC card removal during playout results in read error
>which was not
>> handled. Added a new API to datasource interface similar to
>ferror().
>> Only symbianMMf uses the data source interface now, so adding a new
>> interface does not have any impact on other platforms.
>>
>> Also updated the install pcf file to include meta data
>dll to the
>> video and audio controller package files.
>>
>>
>> Root Cause of the problem: Implementation
>>
>> Files Modified:
>> common/include/ihxmmfdatasource.h
>> common/fileio/hxdatasource.cpp
>> common/fileio/platform/symbian/hxdatasource_ccontent.cpp
>> common/fileio/platform/symbian/hxdatasource_descriptor.cpp
>> common/fileio/platform/symbian/hxdatasourcemmfclip.cpp
>> common/fileio/pub/hxdatasource.h
>> filesystem/local/mini/minifileobj.cpp
>> filesystem/local/mini/minifileobj.h
>> filesystem/progdown/platform/symbian/pdfileobj.cpp
>> clientapps/symbianMmf/audiocontroller/installMMF.pcf
>> clientapps/symbianMmf/videocontroller/installMMF.pcf
>>
>>
>> Image Size and Heap Use impact: no major impact
>>
>> Module Release testing (STIF) : Passed.
>>
>> Test case(s) Added : No.
>>
>> Memory leak check performed : Yes. No new leaks introduced.
>>
>> Platforms and Profiles Build Verified:
>> helix-client-s60-32-mmf-mdf-arm
>>
>> Platforms and Profiles Functionality verified: armv5,winscw
>>
>> Branch: Head & 210CayS
>> <>
>>
>>
>>
>>
>>
>>
>----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> Filesystem-dev mailing list
>> Filesystem-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
>
>
From jgordon at real.com Tue May 29 19:27:29 2007
From: jgordon at real.com (Jamie Gordon)
Date: Tue May 29 19:43:42 2007
Subject: [Filesystem-dev] Re: CR: Fix for PR: 182453 [Server HBF when
sending a SETUP request with x-wap-profile headers.]
In-Reply-To: <3573.192.168.129.21.1179742685.squirrel@mailone.real.com>
References: <3573.192.168.129.21.1179742685.squirrel@mailone.real.com>
Message-ID: <465CE111.5060206@real.com>
[Forwarding to filesystem-dev as Vijendra's having trouble posting to
this list]
This looks fine to me, with one minor change:
> -
> + HX_UNLOCK(m_pMutex);
> _DoSomeReadingFromSocket(TRUE);
> + HX_LOCK(m_pMutex);
>
> HX_UNLOCK(m_pMutex);
> HX_RESULT ReadErr = ProcessPendingReads();
No point locking on one line and unlocking the next, you should just
remove that unlock rather than adding a lock.
Jamie
vijendrakumara@real.com wrote:
>
> Synopsis
> ---------
>
>
> This CR includes fix for PR: 182453: Server HBF when sending a SETUP
> request with x-wap-profile headers.
>
> Quick links to the PR:
> https://bugs.dev.prognet.com/show_bug.cgi?id=182453&link=0
>
> Branch: HEAD
>
> Suggested Reviewer: Darrick
>
> Description
> ------------
>
> The problem is coming when we are sending x-wap-profile header in setup
> request. This time it takes the URL specified in request and tries to
> download the file. This is an HTTP URL.
>
> The problem is that the server blocking indefinitely. I found the problem
> is in _doSomeReadingFromSocket () function of httpfsys.cpp file. Here it
> tries to lock the mutex which was previously locked by the caller of this
> function. So it was waiting indefinitely to get lock on mutex which result
> in server giving HBF.
>
>
> Fix
> -------
>
> Unlock the lock on mutex before calling _doSomeReadingFromSocket () and
> lock it again after called. Changes done at all places wherever
> _doSomeReadingFromSocket () get called.
>
>
> Files Affected
> -----------------
>
> filesystem/http/httpfsys.cpp
>
> Testing Performed
> -------------------
>
>
> Functional Tests:
> ------------------
>
> - Verified by sending setup request with x-wap-profile and getting
> response back and server not giving HBF.
>
>
> Integration Tests:
> - None
>
>
> Leak Tests:
> - None
>
> Performance Tests:
>
> - None
>
>
> Build Verified:
> ---------------
> win32-i386-vc7
> linux-rhel4-i686
> sunos-5.10-sparc-server
>
>
> Platform Tested:
> ----------------
> win32-i386-vc7
> linux-rhel4-i686
>
> QA hints
> --------
>
> - None.
>
> Thanks
>
> Vijendra.
From jgordon at real.com Tue May 29 19:28:40 2007
From: jgordon at real.com (Jamie Gordon)
Date: Tue May 29 19:44:52 2007
Subject: [Filesystem-dev] Re: CR: Fix for PR: 182453 [Server HBF when
sending a SETUP request with x-wap-profile headers.]
In-Reply-To: <465CE111.5060206@real.com>
References: <3573.192.168.129.21.1179742685.squirrel@mailone.real.com>
<465CE111.5060206@real.com>
Message-ID: <465CE158.2080906@real.com>
Oops, attaching original CR.
Jamie Gordon wrote:
> [Forwarding to filesystem-dev as Vijendra's having trouble posting to
> this list]
>
> This looks fine to me, with one minor change:
>
> > -
> > + HX_UNLOCK(m_pMutex);
> > _DoSomeReadingFromSocket(TRUE);
> > + HX_LOCK(m_pMutex);
> >
> > HX_UNLOCK(m_pMutex);
> > HX_RESULT ReadErr = ProcessPendingReads();
>
> No point locking on one line and unlocking the next, you should just
> remove that unlock rather than adding a lock.
>
> Jamie
>
> vijendrakumara@real.com wrote:
>
>>
>> Synopsis
>> ---------
>>
>>
>> This CR includes fix for PR: 182453: Server HBF when sending a SETUP
>> request with x-wap-profile headers.
>>
>> Quick links to the PR:
>> https://bugs.dev.prognet.com/show_bug.cgi?id=182453&link=0
>>
>> Branch: HEAD
>>
>> Suggested Reviewer: Darrick
>>
>> Description
>> ------------
>>
>> The problem is coming when we are sending x-wap-profile header in setup
>> request. This time it takes the URL specified in request and tries to
>> download the file. This is an HTTP URL.
>>
>> The problem is that the server blocking indefinitely. I found the problem
>> is in _doSomeReadingFromSocket () function of httpfsys.cpp file. Here it
>> tries to lock the mutex which was previously locked by the caller of this
>> function. So it was waiting indefinitely to get lock on mutex which
>> result
>> in server giving HBF.
>>
>>
>> Fix
>> -------
>>
>> Unlock the lock on mutex before calling _doSomeReadingFromSocket () and
>> lock it again after called. Changes done at all places wherever
>> _doSomeReadingFromSocket () get called.
>>
>>
>> Files Affected
>> -----------------
>>
>> filesystem/http/httpfsys.cpp
>>
>> Testing Performed
>> -------------------
>>
>>
>> Functional Tests:
>> ------------------
>>
>> - Verified by sending setup request with x-wap-profile and getting
>> response back and server not giving HBF.
>>
>>
>> Integration Tests:
>> - None
>>
>>
>> Leak Tests:
>> - None
>>
>> Performance Tests:
>>
>> - None
>>
>>
>> Build Verified:
>> ---------------
>> win32-i386-vc7
>> linux-rhel4-i686
>> sunos-5.10-sparc-server
>>
>>
>> Platform Tested:
>> ----------------
>> win32-i386-vc7
>> linux-rhel4-i686
>>
>> QA hints
>> --------
>>
>> - None.
>>
>> Thanks
>>
>> Vijendra.
>
>
> _______________________________________________
> Filesystem-dev mailing list
> Filesystem-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
-------------- next part --------------
Index: httpfsys.cpp
===================================================================
RCS file: /cvsroot/filesystem/http/httpfsys.cpp,v
retrieving revision 1.104
diff -u -w -r1.104 httpfsys.cpp
--- httpfsys.cpp 30 Mar 2007 23:36:40 -0000 1.104
+++ httpfsys.cpp 21 May 2007 10:14:00 -0000
@@ -1736,7 +1736,9 @@
while (ulCount > ulCurrentContig && lSocketReadResult == HXR_OK)
{
+ HX_UNLOCK(m_pMutex);
lSocketReadResult = _DoSomeReadingFromSocket(TRUE);
+ HX_LOCK(m_pMutex);
if (SUCCEEDED(lSocketReadResult))
{
@@ -2724,8 +2726,9 @@
}
}
-
+ HX_UNLOCK(m_pMutex);
_DoSomeReadingFromSocket(TRUE);
+ HX_LOCK(m_pMutex);
HX_UNLOCK(m_pMutex);
HX_RESULT ReadErr = ProcessPendingReads();
@@ -3778,8 +3781,9 @@
{
bHandleReadImmediately = TRUE;
}
-
+ HX_UNLOCK(m_pMutex);
_DoSomeReadingFromSocket(bHandleReadImmediately);
+ HX_LOCK(m_pMutex);
if (bHandleReadImmediately)
{
From gwright at real.com Wed May 30 09:09:48 2007
From: gwright at real.com (Greg Wright)
Date: Wed May 30 09:25:45 2007
Subject: [Filesystem-dev] Re: CR: Fix for PR: 182453 [Server HBF when
sending a SETUP request with x-wap-profile headers.]
In-Reply-To: <465CE158.2080906@real.com>
References: <3573.192.168.129.21.1179742685.squirrel@mailone.real.com> <465CE111.5060206@real.com>
<465CE158.2080906@real.com>
Message-ID: <465DA1CC.4000303@real.com>
Looks good to me too with Jamie's comment.
--greg.
Jamie Gordon wrote:
> Oops, attaching original CR.
>
> Jamie Gordon wrote:
>> [Forwarding to filesystem-dev as Vijendra's having trouble posting to
>> this list]
>>
>> This looks fine to me, with one minor change:
>>
>> > -
>> > + HX_UNLOCK(m_pMutex);
>> > _DoSomeReadingFromSocket(TRUE);
>> > + HX_LOCK(m_pMutex);
>> >
>> > HX_UNLOCK(m_pMutex);
>> > HX_RESULT ReadErr = ProcessPendingReads();
>>
>> No point locking on one line and unlocking the next, you should just
>> remove that unlock rather than adding a lock.
>>
>> Jamie
>>
>> vijendrakumara@real.com wrote:
>>
>>>
>>> Synopsis
>>> ---------
>>>
>>>
>>> This CR includes fix for PR: 182453: Server HBF when sending a SETUP
>>> request with x-wap-profile headers.
>>>
>>> Quick links to the PR:
>>> https://bugs.dev.prognet.com/show_bug.cgi?id=182453&link=0
>>>
>>> Branch: HEAD
>>>
>>> Suggested Reviewer: Darrick
>>>
>>> Description
>>> ------------
>>>
>>> The problem is coming when we are sending x-wap-profile header in setup
>>> request. This time it takes the URL specified in request and tries to
>>> download the file. This is an HTTP URL.
>>>
>>> The problem is that the server blocking indefinitely. I found the
>>> problem
>>> is in _doSomeReadingFromSocket () function of httpfsys.cpp file. Here it
>>> tries to lock the mutex which was previously locked by the caller of
>>> this
>>> function. So it was waiting indefinitely to get lock on mutex which
>>> result
>>> in server giving HBF.
>>>
>>>
>>> Fix
>>> -------
>>>
>>> Unlock the lock on mutex before calling _doSomeReadingFromSocket () and
>>> lock it again after called. Changes done at all places wherever
>>> _doSomeReadingFromSocket () get called.
>>>
>>>
>>> Files Affected
>>> -----------------
>>>
>>> filesystem/http/httpfsys.cpp
>>>
>>> Testing Performed
>>> -------------------
>>>
>>>
>>> Functional Tests:
>>> ------------------
>>>
>>> - Verified by sending setup request with x-wap-profile and getting
>>> response back and server not giving HBF.
>>>
>>>
>>> Integration Tests:
>>> - None
>>>
>>>
>>> Leak Tests:
>>> - None
>>>
>>> Performance Tests:
>>>
>>> - None
>>>
>>>
>>> Build Verified:
>>> ---------------
>>> win32-i386-vc7
>>> linux-rhel4-i686
>>> sunos-5.10-sparc-server
>>>
>>>
>>> Platform Tested:
>>> ----------------
>>> win32-i386-vc7
>>> linux-rhel4-i686
>>>
>>> QA hints
>>> --------
>>>
>>> - None.
>>>
>>> Thanks
>>>
>>> Vijendra.
>>
>>
>> _______________________________________________
>> Filesystem-dev mailing list
>> Filesystem-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Filesystem-dev mailing list
> Filesystem-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
Copyright © 1995-2007 RealNetworks, Inc. All rights reserved.
RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.